[…]
J’attends évidemment avec impatience de voir ces belles idées en œuvre. 
Attention le but de GD n’est pas de s’enrichir avec de plus en plus de nouveautés.
Il est à peu près certains qu’il n’y aura pas de nouveaux concepts intégrés à GD de si tôt. Pourquoi ? Parce que mon but est justement d’avoir un logiciel qui propose 3/4 concepts ( Scènes, objets, évènements, automatismes ) qui sont suffisamment puissant et qui se suffisent à eux même pour pouvoir créer tout et n’importe quoi dans de bonnes conditions.
( Certes, les automatismes sont mal intégrés au niveau interface, j’en suis pleinement conscient. Mais question code en interne, ils sont parfaitement integrés et ne sont pas des verrues. ( Je préfère quand même le signaler ) )
Hop là, j’aimerai quand même qu’on évite de critiquer à tout va sans prendre en considération le choix que j’ai fait.
Je ne suis pas du tout d’accord avec ce point de vue :
- Le passage d’une version majeure d’un logiciel ne correspond pas toujours à une nouvelle interface, même si c’est parfois le cas.
- Bien souvent, le passage d’une version majeur correspond plutôt à des nouvelles fonctionnalités majeures ( c’est le cas de le dire ), à une réécriture du logiciel ou à un cassage de compatibilité avec les fichiers des versions précédentes.
- Dans le cas de GD 2, il s’agit précisément d’une fonctionnalité majeure qui est la transcription en C++ puis la compilation en interne des évènements, les mettant au même niveau qu’un langage de programmation classique.
Cette fonctionnalité est véritablement quelque chose qui donne une légitimité totale à un passage à la version 2.
Exemple ? Il me semble qu’il y a pas mal de choses qui sont apparues dans GD2.
Je rappelle encore une fois que le but de GD n’est pas d’introduire des fonctionnalités spectaculaire à chaque version. Au contraire, moins il y en a, plus c’est un signe que la conception du logiciel est bien pensée et aboutie.
Et en parlant de conception bien pensée : Toute les fonctionnalités qui me viennent à la tête ou qui me sont suggérés ne sont pas bonnes à prendre.
Exemple : La bibliothèque SFML qu’utilise GD pour les graphismes est très très bien faite : Simple à utiliser et efficace. Son développeur principal passe son temps à refuser des nouvelles fonctionnalités sur le forum de SFML, car la plupart du temps c’est fonctionnalités alourdirait la bibliothèque pour rien et casserait une conception qui est déjà très bien pensée et qui se suffit à elle même.
C’est déjà le cas ! 
C’est déjà le cas aussi ( Concernant Code::Blocks par contre, il ne se pressent d’ailleurs pas pour sortir des versions “officielles” à jour, et ça leur nuit un peu je pense : Un utilisateur lambda qui télécharge la dernière version officielle se retrouve avec une version complètement datée et croit que Code::Blocks n’a pas évolué depuis. Bref )
Oui, un prototype quoi.
Oui, mais pas à tout prix !
Je veux une interface parfaite, et si elle comporte des éléments de d’autres logiciels, alors ça ne me gène pas ! Tout le monde a de bonnes idées, y compris les concurrents, y compris moi, y compris toi.
C’est pour ça que j’ai fait ce sujet : Pour avoir des bonnes idées.
Celle de victor, qui propose de rassembler groupes et objets au sein de la même liste, me semble excellente : Elle simplifie l’interface, fait moins peur au débutant, et permet de gagner en productivité en ayant directement les groupes d’objets sous les yeux.
Ce que j’ai particulièrement apprécié, c’est qu’il est carrément arrivé avec une image de l’interface et les arguments qui soutiennent son idée.
Je n’ai rien contre le fait qu’on me dise qu’il faut refaire à zéro l’interface de GD, mais dans ce cas montrez moi concrètement comment alors.
( Bon, j’espère que je suis pas trop sec dans ce message, mea culpa si c’est le cas, mais j’ai l’impression qu’on me donne des leçons sans reconnaitre vraiment ce que Game Develop est déjà : Certes les automatismes sont, question visuelle, mal intégrés : Le sujet est là pour proposer des solutions, pas pour me dire que je sais pas concevoir une interface parce que je prends jamais un stylo et un bloc note, ce qui est faux ).
[…]
Bonjour,
Tu m’intéresses là, serait il possible d’avoir un petit lien ?
Avant de participer plus profondément à la discussion, j’aimerais savoir ce qu’il est possible de modifier actuellement dans l’interface de Game Develop. Je me doute bien que tu ne souhaites pas changer tes librairies d’affichage.
Cordialement, Tiger
Oui moi aussi ça m’intéresse
2h, ça fait quand même énorme, Game Develop met environ 30 minutes à se recompiler entièrement et je trouve que c’est déjà trop.
D’ailleurs, 1,5 Go, je trouve que c’est aussi bien énorme pour simplement du code… Game Develop fait moins de 150 Mo de code ( et encore, j’ai compté plein de fichiers qui ne sont pas du code ).
Oui, je suis d’accord.
Je fais quand même rarement plus d’une “cascade” en utilisant Code::Blocks.
( Et puis, il y a quand même pas mal de raccourci clavier intéressant ( Ce qui manque à GD, je l’accord ), genre Alt-G que j’utilise à tout va pour ouvrir un fichier, Ctrl-F/Ctrl-R aussi, F10 que j’ai paramétré pour compiler tout le workspace, F9 pour lancer le project actuel, Ctrl-Maj-S pour tout sauver… )
Ca reste plus simple pour Blender car la spécification d’un fichier 3D n’a que peu d’occasion d’évoluer ( en très gros, il s’agit juste de stocker des emplacements de points ).
Gonfler le poids de GD ne me dérange pas trop ( J’ai bien dit le poids, par contre augmenter la taille du code de GD m’embête, moins il y en a, mieux c’est ), ça reste encore raisonnable.
Ce qui m’embête plus, c’est d’augmenter le poids des jeux. Il y aurait possibilité d’éviter ça en compilant direct dans une dll les évènements plutôt que d’embarquer LLVM dans l’executable des jeux, ce qui permettrait d’économiser pas mal de poids au niveau de GDL.dll.
Ce n’est pas possible, les évènements ont besoin des entêtes livrées avec GD. Mais encore une fois, ce n’est pas ça le plus génant à mon sens.
Comme Tiger et dayvid, je suis très intéressé de voir ça alors.
Je ne vais en effet pas changer de bibliothèque d’affichage, wxWidgets convient très bien pour la création d’interface multiplateformes ( En gros, je peux utiliser pratiquement tous les contrôles fournis par Windows ).
Tu peux regarder la différence entre l’ancienne fenêtre de compilation de Game Develop ( beaucoup trop lourde ) et la nouvelle disponibles dans les dernières versions pour voir un bon exemple d’amélioration à mon sens.
Je n’ai aucune idée de la faisabilité de la chose, mais je vais exposé mon point de vue.
Personnellement, je verrai bien un environnement à la GIMP avec des fenêtres non ancrées. Ainsi grâce à la gestion des fenêtres, on pourrait passer des évènements à l’aperçu très vite en cliquant sur ces fenêtres. La barre correspondante pour chaque fenêtre pouvant être intégré dessus en plus petit (à la place de l’habituelle barre de tache sur les anciens programmes).
Ensuite, je pense que le plus gros du problème vient de l’éditeur de scène, qui est pas hyper pratique. Rien que le redimensionnement des objets est bizarre, ne se faisant pas par les mêmes poignées que les outils habituels (c’est à dire par les coins). Ces mêmes poignées ne sont pas pratiques à sélectionner. Il n’y a pas de sélection multiple avec crtl+clic. Il faudrait, comme les événements, que quand l’on passe le curseur sur un objet sa boite d’information s’affiche et que l’on puisse rapidement modifier ses propriété. Un affichage 3D des objets pour manipuler les objets superposés (comme sur Firefox avec une extension qui permet de voir les éléments d’une page en 3D) sur par exemple un clic molette pourrait être pas mal, mais relève un peu du gadget. Néanmoins les éléments superposés sont assez difficiles d’accès.
Voila pour le plus gros mis en vrac.
Tiger,
Salut,
Oui 4ian mais tous qu’on de fais cella reviendrais t-il pas au même ?!
Non car si l’exécutable entier fais par exemple 2 Mo et que après ta modif il fais que exemple, 500 Ko
mais que la lib fais 1.5 Mo, ça reviens au même donc autant tous laisser comme t-elle !
Pour les images, pourquoi tu ne fais pas comme par exemple Game Maker ou il y as tous dans le fichier sauvegarder ?!
Et bien oui, super pratique 4ian comme truc pourtant, on se soucis pas des images puisqu’elle sont dans le fichier de projet
Dayvid, tu n’as pas compris comment fonctionnait actuellement les jeux GD.
Actuellement :
Game Develop —“Convertit” les événements → C++ —Compilation avec Clang → Bytecode (C’est LLVM/Clang qui génère ce bytecode)
Lanceur du jeu + LLVM —Compile le bytecode—>Code binaire exécutable (qui permet d’exécuter les événements).
Ici, on voit bien que LLVM prend de la place dans l’exécutable du jeu.
Ce qui serait envisageable :
Game Develop —“Convertit” les événements → C++ —Compilation avec Clang → Bytecode —LLVM → Code binaire (dans une dll)
Lanceur du jeu —Charge la dll—>Exécution du code de la dll.
Là, le jeu ne possède plus LLVM, donc il est plus léger (et si ça se trouve, le code binaire prend moins de place que le Bytecode).
[…]
Ah ok merci
Je n’ai rien effacé pour ma part.
De l’assembleur pour un IDE, euh franchement tu est sérieux ou c’est par pure volonté de mélanger les langages et obtenir un truc inmaintenable ?
Sérieusement, tu peux pas annoncer comme ça que tu utilises quotidiennement ton propre IDE qui apparemment renvoi au cimetière Visual Studio, Code::Blocks, Eclipse, et autres Vim ou Emacs pour les puristes, puis dire que tu ne peux absolument rien montrer: Question crédibilité, c’est pas terrible. Montre donc un screenshot d’une partie de l’interface qui à ton sens montre le bon exemple de ce qui faut faire.
Enfin, je veux dire, personnellement quand je commence à parler d’un super truc comme une fonctionnalité de GD, alors soit elle est dans la prochaine version, soit j’explique pourquoi j’ai pas réussi à la faire, soit je dis rien. D’ailleurs, j’ai pas parlé de Game Develop sur le net autre part que sur ce forum avant d’être sûr d’avoir une version utilisable à présenter à tout le monde. Et je n’étais pas majeur à l’époque.
KDevelop est en effet un bon IDE. D’ailleurs, j’ai fait une petite comparaison graphique avec Code::Blocks:
compilgames.net/dl/CodeBlocksLayout.png
compilgames.net/dl/KDevelopLayout.png
Bel exemple d’un IDE “différent” Mais oui, ça reste un bon IDE aussi, dommage qu’il ne soit pas multiplateforme d’ailleurs.
Bref, bref, on s’éloigne légèrement du sujet, je rappelle que tous les avis sont bienvenues tant qu’ils permettent d’aller dans le bon sens, c’est à dire trouver une solution concrète à un problème que vous exposez plutôt que de se perdre en discussions vaines sans faire avancer les choses.
Je ne sais pas si Gimp est un bel exemple d’ergonomie, enfin il me semble que ces fenêtres non ancrées ont été critiquées relativement souvent.
Mais d’ailleurs, pas mal de choses dans GD ( Gestionnaire de projet, éditeur d’objets, debugger, éditeur de calques ) peuvent être déjà séparés de l’interface en déplacant leur barre de titre.
Quand à l’onglet des évènements, on peut également le “tirer” pour afficher les évènements à coté de la scène. ( Si si ! )
Oui, j’avoue, peut être un moyen d’ancrer les objets permettrait d’éviter de bouger ceux qu’on veut pas déplacer.
Je verrais bien une option dans le menu contextuel “Sélectionner un objet…” qui ouvrirait une fenêtre avec tous les objets se trouvant sous le curseur de la souris. L’utilisateur pourrait alors choisir l’objet dans la liste puis valider. Dans ce cas, il faudrait que le clic-droit ne change pas la sélection si l’objet actuellement sélectionné est sous le curseur (pour ne pas re-sélectionner l’objet superposé si on fait appel au menu contextuel).
Maintenant que l’éditeur d’événement est été refait, il serait bien temps d’en faire de même pour l’éditeur de scène.
Il faudrait faire une poignée dans chaque coin et au milieu des côtés de l’objet, avec le curseur qui change quand on est dessus (ça arrive souvent de cliquer dans le vide dans le vouloir). Evidemment, on ne laisserait que la poignée bas-droite si l’objet est très petit (pour pouvoir le redimensionner tout en le voyant).
Les poignées pourraient alors modifier la position de l’objet (exemple, la poignée gauche agrandirait l’objet tout en le déplaçant pour donner l’illusion d’un agrandissement vers la gauche).
Un problème se pose : les sprites. On sait tous depuis le début qu’ils ne se redimensionne pas normalement, mais par rapport à leur origine, ça crée de drôles de résultats. Il faudrait faire en sorte que l’objet Sprite de GD ne fonctionne pas comme les sf::Sprites pour pouvoir faire fonctionner les poignées de redimensionnement correctement (on avait pas une formule pour conserver la position perçue d’un sprite quand on change son échelle ?). Si on règle ce problème, ce sera déjà pas mal, mais il reste la compatibilité avec les anciennes versions de GD : il faudrait “convertir” les anciennes coordonnées de sprites pour que l’utilisateur ne soit pas trop affecté; je dis pas trop car les actions de changement d’échelle ne pourraient pas être adaptées.
Hééééééé, tu t’es carotte tous seul 4ian 
Sa veux dire alors que comme Game Develop à… 4 ans non ?!
Tu aurais donc aujourd’hui 22 ans environ
4ian, quand tu as sortie ta première version de Game Develop, tu avais qu’elle âge juste pour savoir ?!, 17 ans ?! 
La vache, y en as qui sont quand même sacrément douer hein
Dis 4ian, tu t’en sert des fois de ton superbe logiciel pour crée des jeux ?!
Tu dois être sacrément content d’avoir crée se logiciel 4ian, moi je le serais en tous qu’a !
Aller, joue le jeu dis nous 
Je rajouterais une idée en plus de mon ancien post.
Ce serait pas mal d’afficher quand même les objets des extensions (et pourquoi pas les automatismes) non chargées. Si l’utilisateur insère un objet d’un type “non chargé” alors Game Develop ajouterais automatiquement l’extension nécessaire dans le projet.
Ah oui, BONNE IDEE ça, c’est vrais que se serais utile !
Bonjour
Mouais, pour le coup et pour la dernière idée je ne suis pas pour car le principe des extensions, pour moi, c’est dépurer l’interface en cachant les objets et évènements principalement dont on n’a pas besoin donc le fait de les montrer quand même rend les extensions moins utile car leurs seul utilité serait alors d’alléger un peu les jeux compilés…
jérémie14
J’avoue que je partage ce point de vue, j’ai peur que ça déstabilise un peu l’utilisateur par le fait qu’il y ait trop de choses à afficher.
D’un autre coté, c’est vrai qu’actuellement, ça “cache” légèrement les extensions vis à vis de d’autres logiciels qui présentent direct tout ce qui est disponible.
Ou alors, il faudrait un moyen de ranger les objets par groupes, mais le contrôle standard offert par wxWidgets ne permet pas ce genre de chose à priori.
Bonjour
Autrement tu fais un cadre pour les objets existants comme maintenant puis une flèche que, lorsque l’on clique dessus, fait apparaître un deuxième cadre avec les objets dont les objets ne sont pas activées.
jérémie 14
hum pas faux ça…
J’ai une idée…
Faire apparaitre tous les objet mais ceux non activer dans la fenêtre d’extension serons griser !
C’est pas mal ça non car ça permettrais de voir instantanément tous les objet qu’il y à dans Game Develop !
Pour moi c’est une superbe idée vous en pensez quoi ?!
De plus une petite aide ou tooltype pour dire que pour plus d’objet il faut aller dans la fenêtre d’extension ou alors
tu peut aussi faire que l’utilisateur l’active directement en faisant un clique
droit et “activer cette objet” ou un truc du genre s’il est griser !
Voilà !