Questions pour le jeu.

[poshu]

Bonjour les gens,
je suis maintenant étudiant en game design à Montréal (ouais, j'ai repris mes études à 27 ans), et j'ai décidé de participer à un maximum de game jam histoire de confronter un maximum mon savoir théorique à la réalité.

A la base, je pensais utiliser unity (avec la licence de l'école) ou gamemaker (licence qui a été offerte il y a quelques semaines), mais la ludum dare m'a fait réaliser que Pure Basic avait fait de gros progrès dans le domaine de la 2D. Aussi, je vais continuer en Pure, en premier lieu parce que j'y suis très à l'aise, mais aussi en espérant que ça tentera une ou deux personnes de venir tester ce langage merveilleux :3

Hors donc, le nouveau système de sprites me convient plutôt bien, à l'exception notable de l'incapacité de dessiner sur une autre surface que l'écran. Y'a une solution pour ça? Idéalement, travailler sur un sprite avec transparence pour faire de zoulis effets spéciaux (par exemple de la lumière volumétrique?) me semble nécessaire.

Autre question qui tue: que ce soit sous OSx ou sous Windows, avec une manette x360 ou PS4, je n'arrive pas à connaitre l'état de la croix directionnelle alors que tout le reste fonctionne, comment qu'on fait?

[blendman]

salut

Concernant GameMaker, j'ai commencé il y a quelques mois un éditeur de jeu (que je reprendrai lorsque je trouverai du temps) et qui est proche pour le moment de GM :
Voir le sujet : http://www.purebasic.fr/french/viewtopi ... =2&t=14151

L'avantage de mon éditeur est qu'il sort du code purebasic, (en plus de compiler avec le compilateur Purebasic), on peut ajouter des sprites, des objets, des paths, du code, des levels, etc...

Donc, non seulement purebasic est largement capable de concevoir des jeux 2D (rappel :mon jeu Arkeos chronicle, pas terminé, mais suffisamment avancé pour montrer qu'on peut déjà aller très loin en pb).

à l'exception notable de l'incapacité de dessiner sur une autre surface que l'écran. Y'a une solution pour ça? Idéalement, travailler sur un sprite avec transparence pour faire de zoulis effets spéciaux (par exemple de la lumière volumétrique?) me semble nécessaire.

Je suis d'accord avec toi concernant les surfaces directX. On pouvait dans une ancienne version (4.51) dessiner sur un sprite, mais ça a été supprimé.

POur la manette xbox, je n'ai pas testé ça sous PC avec purebasic (je ne savais même pas qu'on pouvait ^^), donc, je ne pourrais pas trop t'avancer là-dessus, désolé ^^

[Ar-S]

@Blendman : 2.51 ?
pas 4.51 plutôt ?

[blendman]

@Blendman : 2.51 ?
pas 4.51 plutôt ?

yep, j'ai corrigé

[poshu]

salut

Concernant GameMaker, j'ai commencé il y a quelques mois un éditeur de jeu (que je reprendrai lorsque je trouverai du temps) et qui est proche pour le moment de GM :
Voir le sujet : http://www.purebasic.fr/french/viewtopi ... =2&t=14151

L'avantage de mon éditeur est qu'il sort du code purebasic, (en plus de compiler avec le compilateur Purebasic), on peut ajouter des sprites, des objets, des paths, du code, des levels, etc...

Oh, mais c'est très intéressant tout ça. Dommage par contre de le baser sur un MDI, tu te coupes directement de osX et linux, mais je comprends la nécessité aussi.

Donc, non seulement purebasic est largement capable de concevoir des jeux 2D (rappel :mon jeu Arkeos chronicle, pas terminé, mais suffisamment avancé pour montrer qu'on peut déjà aller très loin en pb).

J'en suis conscient, mais y'a toujours eu la notion d'effort: utiliser un outil spécialisé dans le jeu peut permettre de gagner un temps précieux dans une jam 48h ou 72h. La notion sprite/sprite3D était particulièrement casse couille avant par exemple...
Du coup, question qui tache, elle ressemble à quoi ta boucle là dedans? T'as fait une state machine? Le gros avantage de gamemaker est -pour moi en tous cas- sa state machine 'achement efficace...

Je suis d'accord avec toi concernant les surfaces directX. On pouvait dans une ancienne version (4.51) dessiner sur un sprite, mais ça a été supprimé.

Ça, ça va poser un gros problème :/

[blendman]

Concernant GameMaker, j'ai commencé il y a quelques mois un éditeur de jeu (que je reprendrai lorsque je trouverai du temps) et qui est proche pour le moment de GM :
Voir le sujet : http://www.purebasic.fr/french/viewtopi ... =2&t=14151

L'avantage de mon éditeur est qu'il sort du code purebasic, (en plus de compiler avec le compilateur Purebasic), on peut ajouter des sprites, des objets, des paths, du code, des levels, etc...

Oh, mais c'est très intéressant tout ça. Dommage par contre de le baser sur un MDI, tu te coupes directement de osX et linux, mais je comprends la nécessité aussi.

En fait, j'ai prévu des version mac et linux (que je développerai quand j'aurai une version windows aboutie).
J'ai déjà commencé en créant des fenêtres séparées pour tester, mais comme je n'ai pas accès à un mac et je n'ai plus linux, pour le moment, je ne peux pas tester ^^.
Mais il y aura une version mac et linux, avec je l'espère le max de possibilités par rapport à la version windows.

J'en suis conscient, mais y'a toujours eu la notion d'effort: utiliser un outil spécialisé dans le jeu peut permettre de gagner un temps précieux dans une jam 48h ou 72h.

C'est pour ça que j'ai commencé mon éditeur.
Etant donné qu'il balance du code pb on peut facilement concevoir un début de jeu, voire un jeu complet et ensuite, l'optimiser si besoin directement avec le code.

Contrairement à GM qui est interprété en plus, PB est compilé. En plus, si on arrête Gm, on perd tout son taff réalisé avec GM, alors qu'avec mon éditeur, on récupère tout sous PB et on peut donc continuer si on le souhaite.

Du coup, question qui tache, elle ressemble à quoi ta boucle là dedans?

J'ai fait plusieurs essais. J'ai voulu au départ ressembler le plus possible à GM.
Dans l'éditeur on peut donc créer des "assets" : sprites, Background, sound, path... qui sont simplement des élements de map() ou list().
Le plus problématique, c'est la notion "d'objets", avec la notion d'event/action.
Car pas d'objets en pure ^^.

Donc, dans Gm, on peut ajouter des variables à un objet et je voulais qu'on ait cette possibilité. Donc, pour chaque objet, si on ajoute des variables personnelles, la solution que j'ai choisie c'est de créer une structure étendue et ensuite de créer un map() (ou list()) avec cette structure (pour l'instant).

Et du coup, j'utilise des macro et non des procedures.
Bref, ça devient vite le bazar .

Ma boucle :
Pour le moment, ce n'est pas du tout terminé, je ne gère presque rien à vrai dire ^^. J'ai juste fait quelques tests pour la compilation et ça fonctionne à peu près.
Voici en gros ce à quoi ressemble ma boucle jusqu'à présent (ça ne prend pas encore en compte l'ajout de variable sur les objets, ni l'ajout de codes...) :
(je l'avais posté sur ce sujet)
http://www.purebasic.fr/french/viewtopi ... =1&t=13965

T'as fait une state machine? Le gros avantage de gamemaker est -pour moi en tous cas- sa state machine 'achement efficace...

je ne sais pas ce qu'est un state machine précisément, mais je pense que ce que j'ai fait doit y ressembler ^^

Je suis d'accord avec toi concernant les surfaces directX. On pouvait dans une ancienne version (4.51) dessiner sur un sprite, mais ça a été supprimé.

Ça, ça va poser un gros problème :/

Il reste les features request
Je pense que si plusieurs personnes demandent qu'on remette ce genre de fonctions Fred y sera sensible

[G-Rom]

mais la ludum dare m'a fait réaliser que Pure Basic avait fait de gros progrès dans le domaine de la 2D

C'est pour cela que PB ne conviens pas pour des plus grosse réalisation, il manque tout un tas de features de base. Aujourd'hui les shaders sont incontournable pour les effets spéciaux, pouvoir faire du batching afin d'avoir des millions de particule à l'écran etc...
PB devrais abandonné ces librairies de base, et intégrer des librairies OpenSource ( SDL / SFML ) par exemple.
Pour ma part , PB me sert uniquement à créer des petites interface fonctionnelle ( éditeur de niveau, éditeur de sprite , de collision , etc...) mais pour le runtime , c++/sfml.
De plus SFML à sorti la branche ios/android en bêta, que du bonheur

@Poshu, tu est du canada à la base ? bravo pour ta reconversion & bravo pour ton petit jeu aussi , je me suis éclaté.

[poshu]

mais la ludum dare m'a fait réaliser que Pure Basic avait fait de gros progrès dans le domaine de la 2D

C'est pour cela que PB ne conviens pas pour des plus grosse réalisation, il manque tout un tas de features de base. Aujourd'hui les shaders sont incontournable pour les effets spéciaux, pouvoir faire du batching afin d'avoir des millions de particule à l'écran etc...
PB devrais abandonné ces librairies de base, et intégrer des librairies OpenSource ( SDL / SFML ) par exemple.
Pour ma part , PB me sert uniquement à créer des petites interface fonctionnelle ( éditeur de niveau, éditeur de sprite , de collision , etc...) mais pour le runtime , c++/sfml.
De plus SFML à sorti la branche ios/android en bêta, que du bonheur

Boarf, en l'état, on pourrait le faire nous même... Si j'avais la moindre idée de ce qu'importer une bibliothèque nécessite xD
Pour tout ce qui est applicatif, pure reste au top, y'a que les webapps pour faire mieux...

[Jenova]

Une solution assez sauvage consiste à ne pas utiliser de sprites mais de la 3D.
Des objets plain et une camera qui les survoles.
Si tu respectes l’échelle 1unité pour 1 pixel c'est pas prise de tête et il y a moyen de calculer la focale et la distance Z(merci à mes amis de ce forum) de la camera pour qu'elle filme l’équivalent de la résolution que tu voulais donner à ton jeu. Du coup à toi les effets de lumières(voir les ombrages) sur ta map.
Comme l’échelle est respecté tu peux gérer les collisions avec le moteur 3D et/ou avec des sprites que tu n'affiches pas mais qui te servent de hitbox à tester.
@+

[poshu]

alors oui, mais ça nécessite de savoir faire de la 3D, et comme mon cerveau est assez limité, je vais me concentrer sur de la 2D, hein ^_^;

[pat]

Si tu restes en 2D, pas d'effet de lumière possible, pas en tout cas en PB.
Il faudra pour ça que tu fasses de la 3D.
Dommage car OpenGL peut le faire en 2D.
A moins que tu te mettes à OpenGL.
Et PB supporte bien OpenGL.

[poshu]

Je fais le tour des techniques là, j'ai un début de binding SDL 2 (basé sur le proto de Luis, forum anglais); j'ai fait pas mal mumuse avec mon wrapper CSFML 2.1 et regardé vite fait les possibilité de GLFW 3.0.4... Globalement, mes préférences vont vers CSFML, mais j'ai des problèmes avec certaines limitations de pb...

Ogl, c'est bien beau, mais va me falloir 6 mois de travail pour obtenir une base suffisante pour que je puisse m'en servir en jam; c'est trop long... Mais au moins, j'ai plusieurs voies ouvertes, je vais voir quoi en faire.

[G-Rom]

Je fais le tour des techniques là, j'ai un début de binding SDL 2 (basé sur le proto de Luis, forum anglais); j'ai fait pas mal mumuse avec mon wrapper CSFML 2.1 et regardé vite fait les possibilité de GLFW 3.0.4... Globalement, mes préférences vont vers CSFML, mais j'ai des problèmes avec certaines limitations de pb...

Ogl, c'est bien beau, mais va me falloir 6 mois de travail pour obtenir une base suffisante pour que je puisse m'en servir en jam; c'est trop long... Mais au moins, j'ai plusieurs voies ouvertes, je vais voir quoi en faire.

J'ai pas eu le temps ce week end de te faire une archive CSFML , tu as réussi de ton coté ?

[poshu]

Bah je bloque sur pas mal de choses, mais ça avance doucement. Le problème principal vient du fait que pure n'accepte pas qu'on retourne une structure, donc on peut bidouiller si la structure fait 64 bits au maximum, mais au dela, j'ai de gros problèmes sur certaines fonction :/
...
Du coup, j'envisage de modifier csfml mais je sais pas la quantité de travaille demandé. J'envisage de poster ce que j'ai déjà fonctionnel et demander de l'aide aussi.

[G-Rom]

de mémoire , il faut que tu re-écrit les structures de base,
pour un sfColor par exemple , une fois la structure créer dans PB , tu y accède via un pointeur

Code : Tout sélectionner

*myColor.sfColor = sfColor_fromRGB(255,255,255)

de mémoire, cela devrais fonctionner.