Bonjour,

J'ai un projet ambiteux (peu être un peu trop mais c'est des rêves qu'on forge la réalité de demain). J'ai vu beaucoup de moteurs de jeux sur les autres langages par exemple comme C# avec unity. Mais je n'en ai pas vu pour le C, en tout cas pas aussi spécialisé. Je veux en créer un, qui traite juste la 2D et qui permettra de faire des jeux plus facilement et de raviver la passion du langage C qui est aujourd'hui considéré par beaucoup comme inutile, désuet et trop bas niveau pour des projets de cette taille.  Je veux créer un éditeur comme unity qui permettra de créer des jeux. J'aimerais avoir vos avis/critiques/conseils.

Voici à peu près la composition du projet:

1) Une petite bibliothèque fait à la main pour créer des "packages", des fichiers les uns à la suite des autres stockés dans un seul fichier comme une sorte d'archive zip (j'aurais pu utiliser des zip sauf que j'ai déjà fait cette bibliothèque et je veux que l'éditeur et les programmes créés avec l'éditeur soient les seuls à pouvoir ouvrir ces fichiers. L'on pourra notament y stocker des images, sons...

2) Un framework basé sur CSFML ou SDL2:

Se chargera donc de base pour afficher des fenêtres et tout. Il doit pouvoir charger dynamiquement et free automatiquement les images par exemple dans images.pkg (et aussi les fonts.pkg, audio.pkg...) ce ne sera pas juste de la csfml/sdl de base on doit créer des fonctions plus haut niveau par exemple au lieu d'écrire des dizaines de lignes pour créer une fenêtre on aura une seule fonction window_new(paramètres)

3) Une autre peite bibliothèque contenant les fonctions souvent utiles (générer nombre aléatoire, créer un fichier de configuration...)

4) un compilateur C pour compiler et lier les bibliothèques ci-dessous pour que l'éditeur puisse lui-même compiler les ses programmes.

Voici comment devra fonctionner l'éditeur. L'utilisateur ouvre l'éditeur, crée un nouveau projet le nomme. L'utilisateur crée une nouvelle fenêtre et définit ses propriétés. La partie gauche affichera l'arborescence des fichiers sources et le milieu contiendra le code C que tapera l'utilisateur, la partie droite contiendra les images, audio et propriétés des différentes parties du projet. Il y aura une fenêtre au milieu où avec TAB, à la place du code on aura un aperçu de la fenêtre du projet et exécuter en temps réel. On crée alors un fichier pkg pour accueillir nos images et on indique au programme qu'il faut charger toutes images placées dans ce pkg et les free automatiquement a la fin. On fait clic droit et importer nouvel image (par exemple background), puis clic droit et dessiner sur tel position avec tel taille... L'uilisateur pourra toujours switcher avec TAB et faire son propre code. On pourra alors compiler le programme dans l'éditeur lui même et le lancer (soit dans la fenêtre d'aperçu soit réellement lancer dans le système). On pourra aussi notament utiliser l'éditeur pour créer ses propres sprites avec la fonction de dessin de sdl par exemple. On pourra manipuler les images façon photoshop mais avec beaucoup moins de fonctionnalités, utiliser des fonctions basiques comme le flou gaussien... Et directement sauvegarder les changements dans image.pkg

Voilà à peu près tout ce que je voudrais mettre en place. J'attend vos avis, sauf ceux qui me diront d'utiliser ce qui a déjà été fait comme unity car moi quand je programme je crée moi-même tout ce que dont j'ai besoin, nous regrettons tous le temps où les hommes étaient encore des hommes et programmaient leus propres pilotes.

-
Edité par Malice13 20 septembre 2018 à 15:57:39

Bonjour l'idée semble sympa.

Si tu y arrive on va peut etre enfin pourvoir retrouver des jeux qui font moins de 70Go ^^.

Par contre je pense que l'IDE n'est pas nécessaire en tout cas pas avant la fin du projet, les éditeurs de textes sont très bien ainsi que les outils come make et gcc, qu'on retrouve en ligne de commande.

Je sais pas trop ce que tu as prévu comme plan de dev, mais je pense qu'il faudrait se concentrer sur le Framework, car pour le reste les outils existent, mais pour la gestion de la 3D avec des objet (genre stl) avec une gestion de colition…) il y a du taf ^^.

Alors bon courage

De la main d'oeuvre serait bienvenue j'aimerais constituer une petite communauté pour travailler avec moi dessus et me conseiller au fur et à mesure vu que c'est quelque chose de vraiment grand qui me dépasse.

Le projet se fera en C intégralement pour l'instant, l'intégration de LUA est à prévoir quand on aura de bonnes bases.

Non, la 3D n'est pas à l'ordre du jour, la 2D donne déjà assez de fil à retordre

Ca fais plaisir de voir quelqu'un qui croit encore que c'est possible de faire des grandes choses en C, autre chose que de l'embarqué !

C'est largement faisable, j'avais moi même déjà fais un projet dans le même genre en quelques mois, qui était beaucoup plus petit c'était plutôt une bibliothèque avec pleins de fonctions pour tout ce qui utile à faire un jeu, en 2D aussi, ainsi qu'un éditeur de map.

C'était une belle aventure et je te conseille de poursuivre ton projet, ça peut t'apporter beaucoup en termes de connaissances dans de nombreux domaines différents.

Par contre je sais pas trop quel niveau tu as, mais je préfère t'avertir que quoi que soit l'idée que tu te fais du temps de travail pour un projet comme ça, la réalité est largement supérieur

Bonne chance, tiens nous au courant !

Je pourrais potentiellement être intéressé, mais je n'ai absolument pas de temps en ce moment pour bosser (entre le taf/mes projet/coupe de France de robotique…), donc au mieux te filer un coup de mains ponctuellement pour debugger, relire, tester, ...

Salut, concernant mes compétences comme tu dis, je pense avoir de solides bases, j'ai déjà fait des dizaines de projets (jeux, applications...) en c/sfml, c/sdl, c/sfml/lua, et la framework löve sur android et pc. Et je sais le temps qu'il faut ne t'inquiète pas j'ai toujours été seul sur mes projets du coup je connais le temps pour pondre quelque chose de bien. Comme toi aussi j'ai déjà une bibliothèque toute prête avec des fonctions pour faire des jeux je l'utilise encore aujourd'hui, mais j'ai voulu le recommencer à zéro pour éliminer les memory leaks, économiser plus de mémoire/cpu, faire plus d'allocation dynamique...etc

Concernant l'avancement du projet, j'ai terminé la bibliothèque pour stocker/extraire les fichiers des packages. J'ai aussi terminé à 75% le nouveau framework basé sur sfml. Reste plus qu'à ajouter des fonctions qui fassent pâlir unity devant mon chef d'oeuvre. Nan je rigole. Il reste donc:

1) Ajouter des fonctions de GUI au nouveau framework (gestion boutons, textinput... Bref tout le tralala des formulaires), j'ai vu qu'on pouvait intégrer GTK+ avec sfml donc si j'y arrive pas (ce qui est normalement impossible) j'utiliserais gtk pour faire la GUI.

2) Un éditeur de texte, bien sûr l'IDE en aura besoin pour ne pas avoir à basculer alt-tab vers notepad++ à chaque fois.

3) Un editeur d'images intégré pour créer/editer ses sprites façon paint à l'intérieur de l'IDE et immédiatement stocker dans les packages.

4) Un éditeur de collision, l'utilisateur pourra dessiner pour chaque sprite les parties où il y a aura collision avec des rectangles/triangles.

5) bof c'est tout ce qui me vient à l'esprit pour le moment.

Vous devez penser que je vois trop grand mais rassurez-vous j'en ai les compétences et de toute façon le but c'est déjà de sortir une première version toute l'amélioration viendra par la suite

Tout ce que tu dis m'as l'air bien, et je pense que tu réussiras a mener ton projet à bien.

Par contre en ce qui concerne l'éditeur de texte, je suis pas sur que ce soit une bonne idée.. Un bon éditeur de texte doit avoir des millions de features qui sont extrêmement longues à implémenter (autocomplétion, coloration syntaxique, linter, des centaines de raccourcis clavier, etc..) et je pense que tu perdras beaucoup de temps à dev ce truc là, alors qu'il est très simple d'alt-tab sur notepad++ par exemple..

Après c'est ton choix, ça peut aussi être très intéressant à dev un editeur de texte !

robyy-22 a écrit:

Tout ce que tu dis m'as l'air bien, et je pense que tu réussiras a mener ton projet à bien.

Par contre en ce qui concerne l'éditeur de texte, je suis pas sur que ce soit une bonne idée.. Un bon éditeur de texte doit avoir des millions de features qui sont extrêmement longues à implémenter (autocomplétion, coloration syntaxique, linter, des centaines de raccourcis clavier, etc..) et je pense que tu perdras beaucoup de temps à dev ce truc là, alors qu'il est très simple d'alt-tab sur notepad++ par exemple..

Après c'est ton choix, ça peut aussi être très intéressant à dev un editeur de texte !

Pour l'éditeur de texte, en plus  d'être long à faire tu devrais t'adapteur à l'utilisateur : gestion des projet / ou non, multiple zone d'édition/ ou non, choix du thème de coloration… En plus tu risque de bloquer des gens qui voudront de la fonctionnalité sans l'outil car ils ont le leur et qu'il leurs convient

ox223252 a écrit:

… En plus tu risque de bloquer des gens qui voudront de la fonctionnalité sans l'outil car ils ont le leur et qu'il leurs convient

C'est vrai que les gens en général n'aiment pas changer d'IDE souvent, et à chaque fois qu'ils prennent en main une nouvelle techno.. Même Unity n'a pas son propre editeur de texte intégré si je ne me trompe pas 

Lu'!

RayleighSilvers a écrit:

Je veux en créer un, qui traite juste la 2D et qui permettra de faire des jeux plus facilement et de raviver la passion du langage C qui est aujourd'hui considéré par beaucoup comme inutile, désuet et trop bas niveau pour des projets de cette taille.

Inutile probablement pas. Désuet, assez clairement, on passe notre temps à payer le fait que C est un langage mal foutu. Trop bas niveau pour des projets comme des jeux 2D, probablement. Pourquoi ? Parce que pour la très, très, vaste majorité de tes mécaniques de jeu, avoir un contrôle très fin des ressources apportent un temps de développement bien plus élevé pour un gain à l'exécution généralement pas perceptible.

D'ailleurs, ce que tu annonces comme étant un projet qui vise à raviver l'attrait pour C entre un peu en contradiction avec :

RayleighSilvers a écrit:

Je veux créer un éditeur comme unity qui permettra de créer des jeux.

Où l'on essaie justement de simplifier au maximum la vue que l'on a du comportement du jeu pour prototyper aussi vite que possible. Et ne pas se prendre le chou avec les détails que C nous oblige à gérer explicitement.

RayleighSilvers a écrit:

1) Une petite bibliothèque fait à la main pour créer des "packages", des fichiers les uns à la suite des autres stockés dans un seul fichier comme une sorte d'archive zip (j'aurais pu utiliser des zip sauf que j'ai déjà fait cette bibliothèque et je veux que l'éditeur et les programmes créés avec l'éditeur soient les seuls à pouvoir ouvrir ces fichiers. L'on pourra notament y stocker des images, sons...

Je dirai que fermer ton format est une mauvaise idée. D'un part, ça va te coûter du temps de développement et en plus ce temps de développement est purement gaspillé : si quelqu'un veut ouvrir ton archive et lire ce qu'il y a dedans, il y arrivera. Il aura par exemple juste à télécharger ton logiciel, le désassembler et hop il pourra voir comment le contenu est pondu et comment il est composé. Et puis surtout ...

Quel est le rapport avec le moteur 2D ?

Et c'est pareil pour les trois points suivants. Tu ne parles aucunement de comment tu veux architecturer le moteur 2D. Ce que tu veux pouvoir faire avec précisément. Et le niveau de contrôle que tu veux donner à l'utilisateur à ce sujet. Bref : tu nous parles de tout sauf du moteur, alors que c'est censé être ça le projet à la base.

RayleighSilvers a écrit:

... car moi quand je programme je crée moi-même tout ce que dont j'ai besoin, nous regrettons tous le temps où les hommes étaient encore des hommes et programmaient leus propres pilotes.

Tu viens de résumer en une phrase pourquoi l'informatique est un bordel sans nom et comment la réutilisation de fonctionnalités existantes est trop souvent jetée à la poubelle alors que c'est ce qui permet d'avoir du code de plus en plus robuste et éprouvé. (Et programmer un pilote, c'est pas le truc le plus intéressant du monde).

Si tu veux que ton projet soit robuste et tienne la route, il va te falloir faire énormément de test automatisé pour garantir que tout est OK. Les projets existants ont déjà ces tests écrits et des dizaines de plus chaque année, toi il va falloir que tu rattrapes ces bases de tests.

ox223252 a écrit:

Si tu y arrive on va peut etre enfin pourvoir retrouver des jeux qui font moins de 70Go ^^.

Dans les 70Go que font les jeux aujourd'hui, c'est les assets qui prennent énormément de place, donc le moteur peut pas faire énormément de choses à ce sujet.

RayleighSilvers a écrit:

... mais j'ai voulu le recommencer à zéro pour éliminer les memory leaks, économiser plus de mémoire/cpu, faire plus d'allocation dynamique...

Il y a comme une contradiction.

-
Edité par Ksass`Peuk 25 septembre 2018 à 15:03:38

@Ksass`Peuk je sais pas si tu as lu ça, mais ça permet de comprendre pourquoi on devrait recommencer à zéro de temps en temps ^^, après c'est vrai que le manque de précision est assez dérangeant, mais bon . Quoi qu'il en soit regardons un peu où ça va aller.

-
Edité par ox223252 25 septembre 2018 à 15:09:04

Oui je l'ai lu. Mais les gens font des parallèles trop rapides sur ce que veut dire l'article.

Le problème pointé ce n'est pas tant la réutilisation du code que l'utilisation de systèmes existants quand il n'y aucune justification, et le fait que le code réutilisé ne reçoit aucun investissement en maintenance pour le simplifier, améliorer sa clarté. Alors qu'il en a nécessairement besoin. Ce n'est pas la réutilisation qui est pointée : c'est la réutilisation à outrance et l'accumulation de dette technique impayée.

Ensuite, quand on reprend un système from scratch, il faut être prêt à payer le prix qui correspond et peu de projets partis dans cette direction sont prêts à le faire effectivement. Réécrire, je ne sais pas, OpenSSL par exemple, ça nécessite d'atteindre le même niveau :

• de clarté,
• de performance,
• de sécurité.

Et pour assurer une adoption derrière, il faut la dépasser sur au moins un des trois critères, sans que cela ne ruine tout espoir de la dépasser sur les deux autres. C'est pas une tâche facile. Peu de gens sont capables de la réaliser ou même simplement d'investir les moyens en temps dedans. Et à moins que l'on soit capable de faire ça, la solution la plus pertinente, et de loin, c'est réutiliser OpenSSL.

Et un autre gros reproche très simple à cet article : il râle mais ne propose aucune solution.

De ce que j'ai compris, RayleighSilvers cherche plus à s'amuser, coder ce qu'il lui plaît, progresser et atteindre son objectif que de faire le game engine le plus poussé et optimisé du monde.

Dans cet objectif là, je pense qu'il est mieux de tout recoder sois même en C, même si c'est vrai que d'utiliser d'autres outils déjà créés et validés, dans un autre langage plus rapide au dev serai plus judicieux pour lui si il voulait faire quelque chose de professionnel etc.. Mais je ne crois pas que ce soit son but, sauf si je me trompe :) 

robyy-22 a écrit:

Dans cet objectif là, je pense qu'il est mieux de tout recoder sois même en C, même si c'est vrai que d'utiliser d'autres outils déjà créés et validés, dans un autre langage plus rapide au dev serai plus judicieux pour lui si il voulait faire quelque chose de professionnel etc..

Même hors de l'optique d'un truc professionnel, c'est faux en fait. Notamment pour apprendre à bien programmer et faire de nouvelles choses à bon escient et pas juste parce que "je veux tout faire moi-même". Tout faire soi-même, c'est s'éparpiller sur sa tâche et vouloir finalement faire trop de choses différentes pour finalement n'en faire aucune correctement.

Reprenons. Si l'on prend le premier post, on a un objectif clair :

• je veux faire un moteur de jeu 2D avec SDL2 ou CSFML.

C'est net, c'est précis et plus important encore c'est réaliste. Et ensuite, on s'éparpille. On veut pêle-mêle :

• un éditeur de texte/graphique pour créer les jeux qui piloteront le moteur, ce n'est plus le moteur, c'est le système qui permet de réaliser le jeu par dessus le moteur, on est déjà plus dans la même tâche,
• on veut un gestionnaire d'assets pour pouvoir gérer les images, les sons, dans un système de package chiffré, (pareil)
• une intégration d'un compilateur dans un IDE pour avoir tout ça avec, (pareil),
• des bibliothèques ... qui pourraient tout à fait déjà exister mais on n'envisage même pas cette possibilité, parce qu'on veut tout refaire soit même.

C'est trop, c'est plus le moteur, c'est d'autres outils.

Ksass`Peuk a écrit:

Même hors de l'optique d'un truc professionnel, c'est faux en fait. Notamment pour apprendre à bien programmer et faire de nouvelles choses à bon escient et pas juste parce que "je veux tout faire moi-même". Tout faire soi-même, c'est s'éparpiller sur sa tâche et vouloir finalement faire trop de choses différentes pour finalement n'en faire aucune correctement.

Je ne dis que ton avis et ta vision des choses est fausse ou mauvaise, mais je ne la partage pas.

Ok commencer la prog par recoder un kernel n'est pas un bon choix, je pense qu'on s'y accorde tous. Mais dans certaines limites "réinventer la roue" reste une très bonne technique d'apprentissage, pour savoir comme fonctionne justement cette roue, et une fois qu'on connait son fonctionnement, on peut utiliser la roue déjà inventée parfaitement.

Pour prendre un exemple, j'ai recodé une bonne partie de la lib C (allant de strlen à malloc en passant par strtok), et j'utilise maintenant tous ces outils en les comprenant et en connaissant leurs fonctionnements. Je ne dis pas que c'est LA meilleur technique, ou que c'est indispensable, mais pour certaines personnes, c'est très utile.

En bref, je dis juste que dire "ça sert à rien parce que ça existe déjà en mieux" à quelqu'un qui veut réinventer la roue, servira juste à le démotiver alors que réinventer la roue peut être une bonne solution parfois. 

C'est comme dire à Pepsi de tout arrêter parce que Coca le fait mieux.

robyy-22 a écrit:

Ok commencer la prog par recoder un kernel n'est pas un bon choix, je pense qu'on s'y accorde tous. Mais dans certaines limites "réinventer la roue" reste une très bonne technique d'apprentissage, pour savoir comme fonctionne justement cette roue, et une fois qu'on connait son fonctionnement, on peut utiliser la roue déjà inventée parfaitement.

Non, c'est toujours pas la question d'ailleurs. J'ai pas de problème avec le fait de réinventer la roue quand on veut apprendre des choses. J'ai des problèmes avec le fait de la réinventer quand ce n'est pas l'objectif actuel. Pour reprendre ton analogie :

robyy-22 a écrit:

C'est comme dire à Pepsi de tout arrêter parce que Coca le fait mieux.

Je ne reproche pas à Pepsi de faire ce Coca fait déjà. Je reproche à Pepsi de vouloir réinventer la composition du sucre alors que ce qu'il veut c'est créer quelque chose de concurrent à Coca-Cola, pas réinventer la formule du sucre. Alors oui effectivement, peut être qu'un jour, ça vaudra le coup pour Pepsi de changer la manière dont il sucre sa boisson pour se donner un avantage. MAIS PAS AVANT d'avoir déjà un produit viable.

Son but c'est faire un moteur 2D. Le reste c'est d'autres tâches.

robyy-22 a écrit:

Pour prendre un exemple, j'ai recodé une bonne partie de la lib C (allant de strlen à malloc en passant par strtok), et j'utilise maintenant tous ces outils en les comprenant et en connaissant leurs fonctionnements.

Tu rêves. Pour les quelques fonctions déclarées dans malloc.h. Il y a 5000 lignes de code dans la libc qui ne font certainement PAS ce que tu as écris dans ton malloc. Tu vois peut être dans les grandes lignes ce que produis malloc. Mais non, tu ne sais pas ce que fait exactement malloc dans la libc. D'ailleurs, il y a peu de développeurs qui sont capables de maintenir cette fonction sans avoir des sueurs froides.

-
Edité par Ksass`Peuk 25 septembre 2018 à 16:45:50

Quand je disais que je comprenais malloc, c'était dans son ensemble "haut niveau", oui c'est vrai que je ne connais pas l'intégralité de chaque fonctions qui sont dans chaque fonctions utilisés par malloc, comme 99,9% des gens, ce que je voulais dire c'est qu'il ne m'arrive pratiquement jamais de faire des erreurs en utilisant malloc. L'exemple n'est peut-être pas bon, je l'admet. 

Je suis d'accord avec toi pour ce qui est de pepsi et de la formule du sucre. Mais je pense que quand on veut apprendre un langage, s'attaquer à un projet un peu (je dis bien UN PEU) supérieure à son niveau, et se casser les dents dessus, ne peut être qu'une bonne chose. 

Je n'avais pas totalement saisi le fond de ta pensée, maintenant que c'est chose faîte, je rejoins ton avis sur une bonne partie des points abordés. La confusion étant sur l'utilité de recoder les outils qui sont eux mêmes outils dans un objectif final, ou recoder l'objectif final, en gros.

robyy-22 a écrit:

Je n'avais pas totalement saisi le fond de ta pensée, maintenant que c'est chose faîte, je rejoins ton avis sur une bonne partie des points abordés. La confusion étant sur l'utilité de recoder les outils qui sont eux mêmes outils dans un objectif final, ou recoder l'objectif final, en gros.

La confusion est souvent là et c'est encore plus vrai quand l'objectif est de développer un jeu. Ou certains développeurs considèrent qu'utiliser un moteur c'est trop facile et quelque part, qu'on ne va rien apprendre. Alors que c'est tout l'inverse : ça permet de se concentrer sur les choses essentielles à apprendre par rapport à la tâche qu'on s'est fixé.

Mon cerveau de 187 a mieux à faire que lire des critiques négatives je l'ai précisé sur la publication. Soit tu me soutiens et me conseilles ou tu te barres et ne postes juste pas. Je dois éclaircir quelques points vu que tout le monde na pas compris:

1) Je ne cherche en rien à faire quelque chose qui dépasse Unity/AndroidStudio, personne n'a dit qu'on allait faire la course contre microsoft.

2) Le truc est censé être amusant et passionant, donc arrêtez de vous prendre la tête. J'attendais des gens qui débattent de comment on va faire quoi et qui connait les outils appropriés, pas un type qui cherche toutes les raisons du monde à ne pas faire le projet.

3) ce n'est pas une perte de temps c'est de l'apprentissage pour moi et pour ceux qui voudraient me suivre, toi t'as peut être tout appris dans le ventre de ta mère mais pas moi. Moi j'ai déjà créé un système d'exploitation à partir de presque rien, alors si t'étais là tu aurais dit "mais pourquoi, t'es con ou tu sais pas que linux existe?" mec si tu dis ça c'est que la programmation tu ne l'as connu que dans la contrainte et l'amertume

4) pas de 4, merci

5) Je reviens sur ce point, quand tu fais un mario sokoban et que tu postes sur le forum les avis des gens t'as toujours le type qui te dit pourquoi coder mario sokoban alors que t'as GTA 5 à côté.

6) Je m'éparpille un peu dans le projet en effet. Mais toi si on te dit de coder une missile balistique tu commences par la fonction qui fait sauter le truc ou la fonction qui guide la missile?

Vous avez tous oublié l'essentiel, moi je fais ça par plaisir, donc si je vous dis que je vais créer un truc comme photoshop bah je le fais, vos avis ne diminueront en rien les connaissances que je vais acquérir ni ma volonté à le faire, si j'ai un truc qui me passe par la tête je le fais. J'ai juste posté ici accessoirement pour voir si quelqu'un pouvait m'aider, pas pour voir quelqu'un taper tout un journal pour me faire comprendre que ce que je fais est une perte de temps. Je l'ai dit, j'aime faire tout moi même, c'est bien sûr pas comparable à ce qui existe déjà, peut être pire, mais j'apprend des choses, je comprend comment ça fonctionne, et SURTOUT c'est amusant.

L'on ne cherche pas à faire un éditeur qui puisse créer un jeu aussi rapidement qu'unity et tout aussi raffiné avec tout l'attirail de .net, on cherche à faciliter la création de jeux en C et aussi à prouver que c'est un langage qui en a encore dans le capot.

-
Edité par Malice13 25 septembre 2018 à 20:54:02

RayleighSilvers a écrit:

Mon cerveau de 187 a mieux à faire que lire des critiques négatives je l'ai précisé sur la publication. Soit tu me soutiens et me conseilles ou tu te barres et ne postes juste pas.

Seulement, c'est pas de chance, tu poses ta question sur un forum public, et les gens ne sont pas forcés de faire ce que toi, tu veux. Par ailleurs, il y a déjà un certain nombre de conseils dans ce que j'ai écris, tu n'es pas obligé de les lire non plus, mais ne reproche pas aux gens qu'ils ne t'en donnent pas dans ce cas.

RayleighSilvers a écrit:

1) Je ne cherche en rien à faire quelque chose qui dépasse Unity/AndroidStudio, personne n'a dit qu'on allait faire la course contre microsoft.

Personne n'a écrit ça, désolé. J'ai l'impression que dans mon premier post, tu confonds la réponse à ton problème, l'analyse des aspects que tu considères comme faux :

• l'inadaptation de générale de C pour ce type de tâche, c'est un fait (ça ne t'empêche pas de l'utiliser quand même),
• le fait que tu veux d'un côté que ce soit programmable en C, mais en même temps tu veux un éditeur de jeu facile d'utilisation, c'est contradictoire,
• le fait que tu veux fermer ton format, qui n'est pas une bonne idée,
• le fait que t'éparpilles.

Et la deuxième partie qui répond simplement au fait que tu dises que tout programmer soi-même est une bonne idée, qui est un tout autre sujet. Et qui n'est pas liée à ton projet : c'est juste un fait général, non c'est globalement pas une bonne idée de tout programmer soi-même tout le temps. Et d'ailleurs je te déconseille de recoder des choses de très bas niveau pour ton projet, genre les gestion de format de fichiers par exemple. C'est de la prise de tête gratuite qui n'apporte pas de connaissance.

RayleighSilvers a écrit:

2) Le truc est censé être amusant et passionant, donc arrêtez de vous prendre la tête. J'attendais des gens qui débattent de comment on va faire quoi et qui connait les outils appropriés, pas un type qui cherche toutes les raisons du monde à ne pas faire le projet.

Et à ce sujet, j'ai déjà répondu : le problème de ton projet actuellement, c'est que si tu as un objectif clair : réaliser un moteur de jeu 2D, tu pars dans tous les sens dès la seconde moitié de ton premier post en voulant ajouter tout un tas de fonctionnalités alors que tu n'as pas encore la fonctionnalité de base.

Je n'ai pas écris que tu ne devrais pas faire ce projet, simplement que tu devrais faire ce projet et pas autre chose. Focalise ta concentration sur cette tâche particulière, il y a déjà LARGEMENT de quoi s'occuper.

RayleighSilvers a écrit:

5) Je reviens sur ce point, quand tu fais un mario sokoban et que tu postes sur le forum les avis des gens t'as toujours le type qui te dit pourquoi coder mario sokoban alors que t'as GTA 5 à côté.

Je n'ai toujours pas écris ça, mais tu le saurais si tu avais lu les posts. Ah par contre attention ! Il y a un piège parce qu'un forum c'est pas un unique dialogue dans un post, des fois, il y a des réponses qui concernent les réponses d'autres intervenants.

RayleighSilvers a écrit:

6) Je m'éparpille un peu dans le projet en effet. Mais toi si on te dit de coder une missile balistique tu commences par la fonction qui fait sauter le truc ou la fonction qui guide la missile?

Je commence par regarder ce que font généralement les gens qui veulent guider un missile balistique. En particulier, je regarde les outils qu'ils utilisent habituellement et comment utiliser le même type d'outil à bon escient pour maximiser les chances que le projet aille jusqu'au bout. Parce que je veux guider un missile balistique, pas coder le truc qui permettra ensuite de guider un missile balistique.

Et pour répondre à la question quand même : ce sont deux tâches indépendantes. Donc commencer par l'une ou l'autre n'a aucune importance.

RayleighSilvers a écrit:

(1) Vous avez tous oublié l'essentiel, moi je fais ça par plaisir, [...]. (2) J'ai juste posté ici accessoirement pour voir si quelqu'un pouvait m'aider, pas pour voir quelqu'un taper tout un journal pour me faire comprendre que ce que je fais est une perte de temps. (3) Je l'ai dit, j'aime faire tout moi même, c'est bien sûr pas comparable à ce qui existe déjà, peut être pire, mais j'apprend des choses, je comprend comment ça fonctionne, et SURTOUT c'est amusant.

(1) Non, on ne l'a pas oublié. Et personne n'a écrit que ce n'était pas le cas.

(2) Et j'ai écris nulle part non plus que ce projet était une perte de temps. En revanche, créer ton format de fichier fermé EST une perte de temps. Sans nul doute : tu ne vas rien apprendre qui a trait à la conception de moteur de jeu 2D. Tu vas juste t'échiner à résoudre un problème qu'il n'est simplement PAS résolvable. Le jeu qui sera créé avec ton moteur aura de toute façon besoin d'être capable de décoder les données, donc de toute façon tu embarqueras le code de décodage dans ton programme et de toute façon on pourra accéder aux données. Tu ne peux pas cacher tes données. Alors utilise une bibliothèque pour zipper ça et tu auras gagné du temps pour les questions liées à ton moteur, il y en a plein.

(3) Vouloir tout faire en même temps, c'est un excellent moyen de ne rien faire. Des débutants qui vont dans le mur parce qu'ils veulent faire trop de choses à la fois, on en voit en permanence, et ils se plantent. Tu as un avantage sur la plupart d'entre eux : ton projet est globalement réaliste. Donc il a de bonnes chances de réussir SI tu te focalises sur ta tâche principale et que tu arrêtes de vouloir faire toutes les fonctionnalités du monde en même temps.

RayleighSilvers a écrit:

(1) on cherche à faciliter la création de jeux en C et aussi à prouver que (2) c'est un langage qui en a encore dans le capot.

(1) Ce n'est pas ce que dit ton post. Ton objectif est réalisable, si tu retires ce que le reste de ton premier post ajoute.

(2) Par contre de côté ... Le langage C a trop de problèmes pour qu'on les ignore. Si on utilise encore C, la majorité du temps, c'est parce que l'on n'a pas le choix. Pas parce que c'est un bon langage : c'est une plaie.

-
Edité par Ksass`Peuk 25 septembre 2018 à 21:42:39

RayleighSilvers a écrit:

Mon cerveau de 187 a mieux à faire que lire des critiques négatives je l'ai précisé sur la publication. Soit tu me soutiens et me conseilles ou tu te barres et ne postes juste pas. Je dois éclaircir quelques points vu que tout le monde na pas compris:

Je ne pense pas que répondre aussi agressivement soit nécessaire. Il a juste voulu t'aider en te donnant des conseils sur ce que tu devrais faire, comme tu le demandes "...me conseilles...".

Il faut savoir que sur les forums, c'est très rare que les gens te soutiennent et te conseilles juste, en général ils le font c'est vrai, mais il y a toujours une partie qui fait l'inverse. Par contre, ce n'est pas ce qu'à fait Ksass`Peuk. Il t'as juste donné son avis, et je trouve ta réponse un peu .. dure. 

Après bien sur tu as raison de vouloir t'amuser en premier, et de te dire que personne ne pourra t'empêcher de faire ça, mais il faut savoir écouter la critique. Au moins l'écouter, après c'est toi qui voit si tu veux en prendre compte ou pas.

-
Edité par robyy-22 25 septembre 2018 à 22:53:59

Ksass'Peuk, tu as raison je te l'avoue, mais je ne suis pas d'accord sur certains points. Mais pourquoi tu dis que les trucs à côté sont des pertes de temps quand ont a déjà des bibliothèques toutes prêtes? Déjà, ne me compare pas aux autres débutants qui s'égarent vite à faire autre chose. Et non ici on ne veut pas créer le projet le plus vite possible en omettant toutes les parties "customisation" pour utiliser des trucs déjà exisants. C'est barbant pour toi de refaire la fonction strlen() par exemple mais pour moi c'est tellement jouissant d'avoir une fonction qui existe déjà mais faite par moi. Je ne sais pas si tu comprends.

-
Edité par Malice13 25 septembre 2018 à 23:09:45

>Mais pourquoi tu dis que les trucs à côté sont des pertes de temps quand ont a déjà des bibliothèques toutes prêtes?

En gros dans un projet, Il faut identifier le cœur du métier et le reste, ce qui fait parti du reste il faut souvent se poser la question  est-ce que c'est vraiment nécessaire, qu'est-ce que ça apporte pour savoir est-ce que je le fait oui/non. 

Donc dans ton cas pour la compression zip chiffré :

• ce n'est pas indispensable,
• ce sera cracké (ça fini toujours par l'être,
• ça ralentira ton moteur de jeux (bon ça ce sera pas forcement visible ^^)

Désolé de m'être emporté, je m'excuse. Jiste que je supporte mal qu'on me dresse dans une optique que je n'ai pas forcément envie de suivre.

En essayant d'appliquer vos conseils on a donc:

1) Se concentrer sur la création du moteur

2) Laisser tomber les projets adjacent

-
Edité par Malice13 26 septembre 2018 à 9:36:50

RayleighSilvers a écrit:

Mais pourquoi tu dis que les trucs à côté sont des pertes de temps quand ont a déjà des bibliothèques toutes prêtes? Déjà, ne me compare pas aux autres débutants qui s'égarent vite à faire autre chose. Et non ici on ne veut pas créer le projet le plus vite possible en omettant toutes les parties "customisation" pour utiliser des trucs déjà exisants.

Pour mettre encore l'emphase sur ce que dis @ox223252, ce n'est pas une perte de temps globale, c'est une perte pour ton projet actuel. Pour que ton moteur soit utilisable et efficace, c'est avant tout sur les fonctionnalités directes de ton moteur que tu vas devoir travailler, pas sur les "à côtés". Et il y a déjà beaucoup de boulot pour que ce soit efficace (et en C, il y en a genre vraiment beaucoup pour que ça devienne utilisable). Alors autant de pas se concentrer sur des éléments annexes :

• ils seront moins stables (parce que tu ne pourras pas y consacrer autant de tests que ce qui existe déjà),
• et moins performants (pour la même raison).

Du coup en faisant ça, si tu as un bug dans ton moteur, ou si tu as une perte de performances qui n'est pas acceptable, tu vas avoir un périmètre plus grand dans lequel il va te falloir chercher le problème alors qu'avec une bibliothèque externe, tu es sûr à 99% que ça vient de ton moteur.

Quand on travaille sur beaucoup de choses différentes à la fois, ça un autre effet pervers : ça ralentit l'apprentissage. Simplement, parce que notre cerveau ne peut pas garder en permanence un grand nombre d'informations, il doit faire du tri, et ce tri prend un peu de temps. Donc si tu sautes d'un sujet à l'autre souvent, d'une part, tu vas inconsciemment faire ce tri à chaque fois, mais en plus tu auras à "recharger" des informations que tu venais juste de virer pour ta tâche précédente. Et ça ne facilite pas le travail d'assimilation non plus.

Et en particulier, tu vas libérer du temps pour faire quelque chose que l'on a tendance à ne jamais voir dans un projet : vraiment tester tes fonctionnalités (bref : apprendre à bien programmer). Sur tous les projets que j'ai pu voir au fil du temps par des débutants/intermédiaires qui veulent attaquer un vrai gros projet, les tests sont toujours inexistants. Or, c'est beaucoup plus important que savoir recoder un bout de libc, et ça va te manger du temps (pour en faire gagner mais plus tard, sur la maintenance et l'évolution du projet). Adopte une approche TDD sur ton projet. Tu vas à apprendre à vraiment maîtriser ce que tu fais et ce n'est pas une tâche annexe : c'est directement lié à la stabilité de ton moteur.

RayleighSilvers a écrit:

C'est barbant pour toi de refaire la fonction strlen() par exemple mais pour moi c'est tellement jouissant d'avoir une fonction qui existe déjà mais faite par moi. Je ne sais pas si tu comprends.

Ré-écrire une fonction telle que strlen ou la plupart des autres fonctions de la libc, c'est intéressant comme exercice pour pratiquer un peu l'algo. Au delà de ça, ce n'est plus utile. Tu ne vas rien apprendre que tu n'aurais pas aussi appris en travaillant sur ton moteur (où tu vas apprendre bien d'autres choses).

Mais il faut se rendre à l'évidence : recoder strlen avec un niveau de performances semblable à ce qu'il y a dans glibc par exemple, même si c'est possible, c'est pas super intéressant. Ça a été fait parce que c'était nécessaire pour une lib qui est utilisée par beaucoup de monde. Tu auras des algos beaucoup plus intéressants à optimiser que ça dans ton moteur.

Je vous remercie tous de vos réponses et je m'excuse de m'être emporté. Je vais finir une première version pour le moteur, faire une petite documentation, et poster le lien pour que vous puissiez tester le projet.

t'inquiète pas s'emporter c'est des choses qui arrivent, tant que les choses se sont remises au claire c'est cool. 

sinon pour les projet annexes tu n'est pas obligé de les laisser tomber totalement, juste ne pas les inclure dans ton moteur et les gérer comme de vrai projets à par entière, après cela peut impliquer de les traiter plus tard, ne foie le moteur fini ^^.

Hey,

J'ai besoin d'un petit coup de pouce par ici, au pire si personne ne peut m'aider je devrais oublier le resize des fenêtres ou la gestion de plusieurs fenêtres.

Salut,

Si ce que tu proposes est une surcouche SDL2, j'ai déjà pas mal de trucs de fait. C'est une lib perso, mais ça se partage. Entre autre l'animation des fichiers gif, du tile map assez automatisé avec un éditeur (un peu pourri mais suffisant pour mes besoins), j'ai un format de fichier pour faire des menus (à boutons ou texte), des animations à base de sprite sheets, de l'affichage / gestion simplifiés de textes (avec ou sans scrolling), de l'input, toute une batterie de micro-fonctions toujours utiles, différents types de temporisateurs, de la table dynamique,  des effets de transition (fondu, rideau, zoom...), une machine à état et ce qu'il faut pour tout mettre dans un unique fichier (datas, images, sons...) et bien sûr pour les en extraire. J'ai même une surcouche pour faire rapidement des trucs avec les claviers logitech à écran genre G15 ou G19 (affichage).

La plupart ne nécessite que de la configuration, par exemple pour faire défiler un texte, je met dans un fichier texte le mode de défilement que je veux, quel type de centrage (gauche par exemple), la taille de la police, le nom de la police et le texte à afficher. Ensuite, c'est passé à la moulinette vers un format de fichier que j'ai créé. Dans mon programme, j'ai juste à ouvrir le fichier et j'ai un jeu de fonction du style start/stop/destroy pour gérer.

La plupart des trucs (gif, animation, transitions, menu, texte avec scroll, affichage G19 ...) sont utilisés pour revolver (DL sur mon site) et le tilemap, la météo et la machine a état dans mon projet en cours :stringman (ma signature).

Maintenant, je fais ça pour moi parce que c'est ce qui m'amuse. Si "avoir fait un jeu" était la vraie finalité, j'utiliserais probablement un des 200 softs disponibles pour faire des jeux rapidement comme game maker, construct, AGS et j'en passe.

M'enfin, selon moi la "passion" du langage C dont tu parles vient justement de l'intérêt que l'on trouve à faire soi-même sa petite cuisine, du moins pour ceux dont ce n'est pas professionnel. Si je veux du tout cuit, je vais passer par un soft dont c'est le job, et je me vois mal atteindre le niveau d'un Unity dans un temps raisonnable même pour "juste" de la 2D...

Bonne continuation.

Salut drx, merci de répondre à ce sujet. Non pour ma part ce que je veux n'est pas utiliser ce que tu as fait je voudrais plus m'inspirer et par là même améliorer ton concept et rajouter ma sauce, en plus je suis sous SFML et toi SDL. Merci d'avoir proposé ton outil et d'ailleurs j'aimerais que tu me passes ça pour que je puisse m'en inspirer, le fait est que je veux le faire moi-même et utiliser des outils créés par la sueur de ton front est un peu ingrat. Je ne cherche pas à atteindre tel ou tel niveau d'un éditeur d'autrui, je veux voir ce que je peux faire moi-même, même si c'est pas aussi bon que le tien, c'est juste avoir la satisfaction d'avoir fait quelque chose de ma courte vie

-
Edité par Malice13 29 septembre 2018 à 15:53:52