Arkeos Chronicle / 3 Arks - Aventure RPG (moteur 2D iso)

salut

voici les news du jour (ou plutôt des soirée et week end précédents ).

Tout d'abord, je voudrais remercier très chaleureusement ceux qui m'ont aider à résoudre certains problèmes. Je pense notamment à Bibi675, grâce à qui le chargement des maps est 30 fois plus rapide .
Merci aussi à Jo et à ceux qui m'ont apporté leurs conseils .

New 28/04/2010:
Editeur & Jeu :

>> modification du chargement des images : j'ai ajouté un objet "bibliothèque" qui charge dorénavant les sprites de la room actuelle. Ensuite, chaque objet va cherche son sprite à partir de cet objet bibliothèque. Avant, je chargeai -sans le savoir- à chaque nouvel objet crée le sprite, même s'il était utilisé par d'autres objets.
C'est la raison pour laquelle certaines maps mettaient plus de 12 secondes à charger.
Une petite comparaison :
* avant : 100 objets + 70 sols : chargement 12 à 15 secondes.
* maintenant : 1700 + 500 sols : chargement 1 à 4 secondes . yahoutch.

- Du coup, cela a résolu mon problème avec les images de sols immenses (5000*4000) : plus besoin de ça.
Autre avantage, je peux à nouveau avoir un très grand nombre de maps, utilisant les mêmes images.

>>Je suis repassé à GM8, afin d'utiliser les png pour les sols (et pour la compatibilité vista/7, pour la rapidité, l'utilisation de GEX, dll spécifiques, etc...). J'ai finalement laissé tomber la méthode sprite_set_alpha_from_sprite, où j'utilisai un sol.jpg (motif) et un sol.gif (alpha). Le jeu sera plus lourd donc un peu plus long à télécharger, mais du coup, beaucoup plus rapide en interne (chargement de maps).


JEU
>> J'ai fait quelques tests avec les particules et l'excellent utilitaire "particle designer". Bon, je n'ai pas encore réussi à créer de système vraiment isométrique. Peut-on d'ailleurs transformer un système de particule que l'on aurait créer ? ou quelque chose comme ça, je ne sais pas.

Je me demandais s'il valait mieux : utiliser des particules ou un gif animé pour des sorts de magies, lorsque l'on peut utiliser les 2 ?
Autre question :
- pour le moment, je charge les fichiers des particules en externes (gml) avec un execute_file() ou execute_string(), mais ce n'est pas très protégé, car on peut alors lui faire exécuter ce qu'on veut.
Y'a t'il moyen d'empêcher d'exécuter n'importe quoi ?

>>modification de l'affichage des ennemis sur 1 même map. J'avais mis pour le moment 3 types d'ennemis différents par map. J'ai ajouté des paramètres aléatoires de taille et de couleur pour varier un peu tout ça.

>> j'ai continué à travailler sur l'IA et le déplacement des ennemis.



Editeur :
>>ajout de petits objets de décors (barrières, poteau..) et de FX (feu, fumée..) : avec possibilité de modifier leurs paramètres (taille, couleur, orientation, effet "sort" (pour les sorts et fx), etc...

>>modification de la façon de charger des images : pour faire , avant je ne savais comment connaitre le nombre d'images dans un dossier, donc, j'utilisai un fichier ini pour le déclarer : c'était pénible et galère de le changer dès que j'ajoutai une image. Maintenant, grâce à Nicoulas (et la fonction recherche), je sais comment on le fait et c'est beaucoup plus simple à gérer .

>>ajout d'une partie "interface" (pour créer les interfaces, et autre menus) et d'une partie bibliothèque (pour créer les bibliothèques d'images) > pour l'instant ces parties sont vides, mais je les remplirai progressivement.

[TheDarkTiger] a écrit:

La taille du BMP, c'est la taille en RAM !
(voir en RAM de la carte graphique si t'as pas de bol)
Découpe moi ça en morceaux de 1024*1024, et affiche celle où est le héros, plus celles le plus proche de lui ... (ça en fait 4 à afficher du coup).
draw_background(1024*floor(x/1024),1024*floor(y/1024),background);

J'ai changé la méthode pour les sols, donc, ça va beaucoup mieux, je ne charge plus que des petites images répétitives + 1 "petit background" (500*400 par exemple).

Par contre, ta technique me semble très intéressante pour faire une sorte de chargement si le personnage est à proximité des objets.
On peut faire ça avec ta méthode ?

Devil37 a écrit:

Je suis d'accord avec TDT, si ton moteur est bien codé, ça ne devrait pas ramer. (Enfin si les machines des joueurs ne sont pas aussi anciennes que la mienne *hum*).

Il était visiblement mal codé, mais j'ai corrigé ça et c'est beaucoup mieux (grâce à Bibi675 .

Citation :

C'est à toi de voir si tu préfère avoir un bon rendu mais un poids + important et des perf' réduites avec du PNG, ou rester sur du JPG.

Pour les background, le jpg est pas mal. Pour me sols, je suis en png. Et pour les décors, je vais faire des tests.

Citation :

Tu as toujours la possibilité de compresser et décompresser tes images en temps réel. Le chargement sera plus long si in-game tu fais tout en même temps, mais si tu prévois le dézippage avant que la carte doit être chargée (tu anticipe sur le jeu quoi), tu réduiras la taille du dossier du jeu.

Je compte compresser effectivement (et encrypter certaines choses).
Par contre pour le dézippage, je ne sais pas trop comment dézipper avant d'arriver sur la nouvelle carte, car on dézipperait alors qu'on est la précédente, ça pourrait la ralentir, non ?

Citation :

L'éditeur de jeu est vraiment un truc à développer pour du rpg. Je dis ça parce que moi-même je développe en ce moment un éditeur multi-fonctions qui est assez avancé maintenant (mais en 3D par contre :pac_dr:). Mon but est que n'importe qui dans mon équipe puisse utiliser le logiciel en toute simplicité, et ce même si les connaissances dans le domaine sont faibles. A défaut de rendre accessible l'éditeur aux autres, c'est pour toi un investissement rentable de temps, tu le verras par la suite !

Pour l'éditeur, je suis tout à fait d'accord, c'est la raison pour laquelle je passe beaucoup de temps dessus, mais je ne le regrette pas car je réalise du coup une map en quelques minutes .

Citation :

Je tiens à dire que tes rendus sont vraiment esthétiques continue comme ça, ya du gros potentiel si la prog' assure !

Merci, grâce à ceux qui me donnent des conseils, des techniques, la prog commence à être mieux .
Donc, ça devrait être une démo assez cool au final.

blendman a écrit:

Tout d'abord, je voudrais remercier très chaleureusement ceux qui m'ont aider à résoudre certains problèmes. Je pense notamment à Bibi675, grâce à qui le chargement des maps est 30 fois plus rapide .

Mais de rien. ^^

Pour ta question, moi je serai plus pour les particules avec des positions aléatoires afin d'éviter les répétitions, c'est aussi la solution la moins couteuse en taille du dossier de jeu et c'est pas trop gourmand en perfs.

Ou alors tu fais plusieurs sprites différents créés en aléatoire .

Déjà que son chargement prends quelques secondes, il va pas s'embêter à créer ses animations dynamiquement...

bibi675 a écrit:

Déjà que son chargement prends quelques secondes, il va pas s'embêter à créer ses animations dynamiquement...

non ce qu'il a dit est intéressant car c'est ce que j'avais fait lros de mes tests (j'ai testé 3 méthodes) .

Je crois que j'utiliserai 2 méthodes en laissant le choix dans les options si jamais ça consomme trop de mémoire, on verra .

Sinon, quelques news :
Editeur :
- j'ai ajouté un zoom/dézoom et remise à zéro de la vue. C'est très pratique.
- j'ai aussi ajouté une mini map dans l'éditeur, au besoin.


Jeu :
- j'ai effectué les changements nécessaires pour que tout fonctionne avec le nouvel éditeur (donc les ajouts de petits décors et fx).
- j'ai changé le système d'ombre automatique pour les gros objets.


Et voici un nouveau screenshot de la dernière version :

Spoiler:

blendman a écrit:

bibi675 a écrit:

Déjà que son chargement prends quelques secondes, il va pas s'embêter à créer ses animations dynamiquement...

non ce qu'il a dit est intéressant car c'est ce que j'avais fait lros de mes tests (j'ai testé 3 méthodes) .

Ben j'ai pas dit que c'était pas intéressant, j'en déduis juste que ça rallongera le temps de chargement... Enfin bon, c'est toi qui voit car moi la taille en RAM personnellement je m'en fiche, j'en ai 4 Go. (je rigole hein, plus ce sera optimisé mieux ce sera, surtout pour les petites configs)

Sinon le screen est magnifique comme toujours mais cette fois, il est plus remplis, bon travail !

salut

Voici quelques news du projet .

Quelques tests avec d'autres engine ou langage
Après avoir fait des tests très intéressants avec construct (qui est beaucoup plus performant que GM8) et Game Develop, j'ai continué d'avancer sur ma démo.

De plus, j'ai aussi fait des tests avec un ami en c++/ avec SDL+openGL, histoire de voir ce que cela donne. C'est plutôt performant

La bonne nouvelle est que je vais me servir de l'éditeur que j'ai réalisé et que j'ai continué pour la version officielle du jeu (qui est une version en ligne, faite en java par un dev confirmé ).

Editeur :
- on peut désormais ajouter et bouger des objets avec le zoom maximum, ce qui est très pratique.

Spoiler:

- j'ai ajouté des propriétés aux objets comme des couches (ou des calques) car je vais ajouter bientôt un système de calques. Enfin, je vais essayer
- possibilité d'exporter les maps réalisées pour le jeu Java
- j'ai aussi commencé à réfléchir à la possibilité de créer une bibliothèque d'image (avec par exemple modification du centre (origine de l'image), de l'ombre, etc...)
[edit - j'avais oublié ça ]
- ajout de pnj avec des options : nom, dialogue, quete, etc..
[/edit]
- correction de quelques bugs et optimisation du code.


Jeu Offline (GM) :
- j'ai ajouté les icones et boutons de l'interface du bas, avec les menus correspondant, et les propriétés des menus pour le personnage : par exemple menu caractéristiques : expérience, vie, mana, force, dextérité, etc..

Spoiler:

Les menus ne sont pas terminés, je dois d'ailleurs encore ajouter des informations dessus.

- j'ai aussi ajouté les caractéristiques de l'ami du joueur (un des compagnons, car on en aura plusieurs pour nous aider)
- On a aussi la possibilité de définir le comportement que l'on veut qu'il adopte (doit-il attaquer, nous soigner, ne rien faire, etc..). Si vous avez des idées d'autres comportements, dites-le moi et je verrai si c'est intéressant, je les ajouterai

Spoiler:

Jeu (version officielle-java) :
- comme je le disais, je peux désormais exporter les maps créées avec mon éditeur réalisé avec Gm pour la version Java. la map est enregistrée dans un format type xml et ensuite lue par le jeu réalisé lui en java.

Graphismes
Bah vouich, parce qu'il faut aussi en parler, hein .

J'ai donc retoucher pas mal de sprites et créer de nouveaux sprites aussi.
De plus, j'ai commencé à faire des tests d'armatures avec blender pour les futures animations des personnages.
Pour cela, je suis aidé de Kiopaa qui m'a gentiment modifié et amélioré une armature afin de me permettre de faire des animations plus sympa .

Enfin, j'ai réalisé des nouveaux dessins de monstres, animaux, objets, maisons...

voilà, c'est tout pour aujourd'hui, mais c'est déjà pas mal .

Sinon, j'ai hâte de tester la version du moteur de lumière de Bast

ps : bibi675, si à l'occasion tu veux passer sur msn n'hésites pas, j'aurai encore 1 ou 2 questions pour toi .

Wouah, déjà la version online en Java ?!
J'ai quand même une question : comment tu vas faire pour le serveur ? Tu vas commencer en l'hostant sur ton propre PC ou tu vas prendre un serveur payant ?

En tout cas c'est du bon boulot, bravo !
Je vais essayer de me connecter sur MSN aujourd'hui.

bibi675 a écrit:

Wouah, déjà la version online en Java ?!
J'ai quand même une question : comment tu vas faire pour le serveur ? Tu vas commencer en l'hostant sur ton propre PC ou tu vas prendre un serveur payant ?

On a pris un serveur payant, histoire d'avoir de bonnes performances .
Pour la version online (en java), on l'a commencé avant ma version GM. Mais l'éditeur nous prenait beaucoup de temps. Du coup, maintenant, comme le développement de l'éditeur est "facilité" avec Gm, et que je m'en occupe, le dev peut se concentrer sur le jeu .

Citation :

En tout cas c'est du bon boulot, bravo !
Je vais essayer de me connecter sur MSN aujourd'hui.

cool. Mais connectes-toi quand tu as le temps, c'est pas pressé .

Ok, et c'est quel hébergeur sans être indiscret ?

Vu que t'es apparemment online, je vais me connecter de suite.

bibi675 a écrit:

Ok, et c'est quel hébergeur sans être indiscret ?

Comme je te disais on va en tester plusieurs (ovh pour le moment).
On en prendra un par la suite pour le jeu, en changeant au besoin si on a beaucoup de joueurs, ce que l'on espère .

Sinon, grâce à cet Excellent Bib675 qui m'a expliqué comment utiliser les listes, j'ai pu ajouter ça dans mon éditeur :
- des calques (10) : sur lesquels se trouvent les différents type d'objets. Par exemple, le background est sur le 1, les sols sont sur le 2, les fleurs sur le 3, les autres décors (arbres, rochers, plantes) sur le 4 , les personnages sur le 5, etc.. L'avantage étant que je peux afficher ou pas les éléments de chaque calque, c'est pratique pour bien visualiser certains éléments (pour les chemins et route par exemple).
- je peux dorénavant afficher et sauver les listes des sprites utilisés pour chaque map (un grand merci encore à Bibi ), ainsi que la liste des objets présents sur la map. Pour ça, il faudra que je trouve le moyen de faire un système avec un ascenseur parce que je vais avoir beaucoup d'objets .
- j'ai ajouté d'autres petites bricoles sur l'éditeur (des objets "généraux" pour la future bibliothèques d'images que je vais mettre en place prochainement par exemple .

Ouah t'as implémenté tout ça grâce aux listes, pas mal !

Bonne idée ces "calques" comme dans un éditeur graphique, ça peut vraiment s'avérer utile

nicoulas a écrit:

Bonne idée ces "calques" comme dans un éditeur graphique, ça peut vraiment s'avérer utile

carrément .

j'y mets mes différents objets : background, sols, fleur, décors, nuages, puis post-FX (genre bloom, flou..), puis interface (plusieurs couches) et enfin la souris (cursor).
Comme ça, si je veux bien voir mes chemins, je n'affiche que les sols et hop .


Sinon, un petit test de posing récemment réalisé (un grand merci à kiopaa du Blender-clan qui m'a réalisé une superbe armature pour mon personnage) :

Comme d'hab : magnifique ! :coeur2:

Incroyable.

salut

je relance ce sujet car j'ai commencé à me remettre tout doucement sur le jeu 3arks. J'avais fait un grosse pause et bossé sur mon logiciel animatoon, et comme il est pas mal avancé, j'ai un peu plus de temps pour mon jeu.

En plus, j'ai appris pas mal de choses grâce à animatoon, et donc, je vais esayer de reporter sur 3arks .

Sinon, j'ai dans l'optique d'essayer de faire une petite version online (un truc tout cool, pas du gros mmo).
j'ai commencé à regardé du coté de 39dll, j'avais déjà fait une démo de moonkiroe avec il y a 3 ou 4 ans, et je recherche des informations ou des technique sur les jeux en lignes et aussi sur la sécurité pour ces jeux (encryption, protection...).
Enfin, si vous avez des conseils n'hésitez pas .

ben au niveau protection déjà il ne faut jamais laisser de variables genre argent, position du perso etc... autonomes dans le client, il faut impérativement que ce soit le serveur qui les stockes et "rafraichisse" les variables de ton client. C'est pour éviter le memory editing. Et de toute façon il y a des fonctions encryptage dans la 39dll.
Tu peux aussi utiliser MD5 variable guard => http://gmc.yoyogames.com/index.php?showtopic=386714 ; DHP Daz Hack Protection => http://gmc.yoyogames.com/index.php?showtopic=335728 ou Gm Antihack => http://gmc.yoyogames.com/index.php?showtopic=338771

Phenixprod, merci pour ton message et les conseils .

PHENIXprod a écrit:

ben au niveau protection déjà il ne faut jamais laisser de variables genre argent, position du perso etc... autonomes dans le client, il faut impérativement que ce soit le serveur qui les stockes et "rafraichisse" les variables de ton client. C'est pour éviter le memory editing.

yep, c'est ce que je vais essayer de faire, même si c'est pas évident .
le memory editing, c'est modifier les variables ingame avec des trucs genre cheat engine ? Je n'y connais rien mais je pense qu'il va falloir que je me renseigne un peu sur tout ça pour voir comment l'empêcher (au moins un peu, histoire que ça décourage la plupart de ceux qui voudraient tricher ou pirater le jeu).

Citation :

Et de toute façon il y a des fonctions encryptage dans la 39dll.

Ah, je ne les connais pas. Il va falloir que je vois ça. On peut trouver des infos là-dessus ?

Citation :

Tu peux aussi utiliser MD5 variable guard => http://gmc.yoyogames.com/index.php?showtopic=386714 ; DHP Daz Hack Protection => http://gmc.yoyogames.com/index.php?showtopic=335728 ou Gm Antihack => http://gmc.yoyogames.com/index.php?showtopic=338771

j'ai regardé les liens, mais impossible de tester quoique ce soit, car tous les liens donnés dans les sujets sont cassés.
Alors si quelqu'un a ces dll, ça m'intéresse.

Sinon, j'ai fait un test avec armadillo, pour protéger un exe créé avec GM, il faudrait que je le poste pour voir si c'est facilement piratable ou pas.

Je sais pas comment tu fais pour avoir autant de talent en graphisme/programmation/modelisation/dessin, es-tu dieu ?

C'est pas possible, dieu existe déjà.

Spoiler:

C'est surtout qu'il a une longeur d'avance sur nous (l'age entre autre)

salut

Bon après avoir réfléchi à la suite que je pouvais donner pour ce jeu "3arks", j'ai décidé, avec l'aide d'Ombre, de le développer en purebasic (voir le sujet que j'ai écrit sur purebasic dans la section programmation ).

Ombre s'occupe donc du serveur et du moteur online, et je me suis mis à l'apprentissage de ce langage simple, puissant et performant.
L'avantage de ce langage est qu'il est à la puissant (utilisation de directX 9 de manière transparente) et très facile à apprendre, avec même quelques points communs avec le GML .

Ce qui m'a motivé pour changer de langage, c'est le fait que :
- le purebasic soit performant, et visiblement suffisamment pour la réalisation d'un jeu 2D comme 3arks
- le purebasic soit rapide à apprendre et assez simple, même pour un nonoch comme moi .
- game maker soit vraiment super nul pour la protection du jeu, donc pour un jeu commercial en ligne, c'est vraiment pas super. Dommage parce que j'avais déjà beaucoup avancé sur ce jeu avec ma version GM .

Mais en même temps, purebasic est très intéressant et niveau performance, et on a facilement de l'aide sur les forums dédiés, c'est très encourageant .

Voiloutch, j'essaierai de vous tenir au courant de nos avancées et si vous souhaitez vous mettre à purebasic n'hésitez pas .

le purebasic dont tu parle ce ne serait pas la même chose que le basic de 3d gamemaker qui était vendu en fnac et autres car je l'avais acheté et après quelque essais et recherche internet
les productions "amateurs" était du même ordre que ce qu'on trouve avec game maker bon en 3d mais étant donné que c'est un language de haut niveaux les performances ne sont pas au rendez vous!

pourquoi n'apprend tu pas directement le c++?vu la qualité de ce que tu nous présente je pense que tu perd du temps.

marty a écrit:

le purebasic dont tu parle ce ne serait pas la même chose que le basic de 3d gamemaker

ce n'est pas la même chose. Je crois que tu parles de dark basic. Je ne connais pas dark basic.

Citation :

le basic de 3d gamemaker qui était vendu en fnac et autres car je l'avais acheté et après quelque essais et recherche internet
les productions "amateurs" était du même ordre que ce qu'on trouve avec game maker bon en 3d mais étant donné que c'est un language de haut niveaux les performances ne sont pas au rendez vous!

A mon avis, niveau performances, on va quand même plus loin qu'avec GM . De plus, niveau sécurité, étant donné que le code est compilé, non seulement ça va plus vite à l'exécution, mais en plus, je pense que c'est plus sécurisé que GM .

Citation :

pourquoi n'apprend tu pas directement le c++?vu la qualité de ce que tu nous présente je pense que tu perd du temps.

pourquoi je ne le fais pas en c++ ?
la principale raison est celle-ci :
- j'ai essayé de me mettre au c/c++ depuis 2008, et je n'ai jamais réussi à persévérer ni à obtenir quoique ce soit de performant (sans doute car je suis nul en c/c++, mais aussi parce que la SDL seule (non couplé à openGL) ne me semble pas très performante pour les jeux). Il n'est pas dit que plus tard, d'ici quelques temps, je ne passerai pas au c++ (mais après avoir terminé ce jeu, bien sû)

C'est donc la raison pour laquelle le purebasic me convient : je comprends assez facilement ce langage, je le trouve rapide, performant, et simple . Le c++ il me faudrait au moins 1 ou 2 ans pour commencer à me sentir à l'aise. Avec le purebasic, il me faudra 1 ou 2 mois .

Je me rappelle lorsque j'ai discuté avec Anthony, un copain, qui faisait un jeu en flash. Dans la ruche d'entreprise dans laquelle je bossais, il m'avait dit que beaucoup de personnes bossant dans la même boite de jeu que moi s'étaient moqué de lui et de Camille (son associé - développeur), parce que leur jeu était en 2D (et pas en 3D) et en plus en flash.
Résultat aujourd'hui : leur jeu Dofus ne me semble pas avoir été une mauvaise idée finalement , ainsi que le choix de flash pour sa conception .

Pour conclure, je dirai que ce qui est important, c'est de trouver un langage qui te corresponde, te plaise et qui te permet d'aller au bout de ton projet, si les performances te satisfont .

Pourquoi je ne le fais pas en c++ ? Parce que sinon, dans 5 ans je n'aurai toujours pas de jeu, tout simplement . Avec pb, j'ai déjà un moteur graphique (en seulement une dizaine de jours).

Lol pour dofus, marrante l'anecdote :p

Sinon ouai, faut utiliser un langage avec lequel on ce sent bien pour développer un jv.
Après chacun ses gouts.
Perso les langages haut niveau ça a des réactions allergiques sur moi :p , pis j'aime bien avoir le contrôle total (comprendrons ceux qui ont déjà testé de dev sur gba xD)

Pis une chose importante a savoir, c'est que qq soit le langage que t'utilise, une fois que t'auras finis ton jeu, ben c'est con de le dire mais il seras FINI, et
rien ne t'empêche de migrer sous un autre langage pour en faire un version améliorée (ce qui est beaucoup plus simple que de refaire un projet 0, étant donné qu'il faut juste programmer, tout le reste est fait !)

En tout cas bonne chance

tu pourras essayer SFML pour la 2d, c'est une sorte de SDL destinée au C++, les performances sont meilleures aussi.

Je poste ce message juste pour dire que le purebasic me gave parce qu'à chaque fois que je présente le langage les gens restent fixer sur le mot 'basic'. Pour moi c'est un langage à part, pour ne citer que quelques trucs :
-Possibilité de marquer de l'assembleur directement dans le code (j'ai jamais utilisé mais je testerais bien).
-Un mec a réussi à ajouter la POO sur purebasic (il n'est pas soutenu par les développeurs) mais le mec propose les scripts, ect..., sous forme de Macro qui transforme PB (purebasic pour les connaisseurs) en langage supportant la POO
-La rapidité et la taille des exe sont comparable au C (oui quand on compile le programme le plus 'idiot' possible 'hello world' en console, l'exe ne fait pas 3 mo !).

Pour moi purebasic la seul chose qui le relie au 'basic' c'est sa syntaxe, et encore, je connais pas le basic mais je penses que le purebasic ajoute quelques trucs inexistants. Si quelqu'un connaissant bien le C ou le C++ serait près à faire un programme de test dans le but de tester les perfs et de le comparer à un programme faisant les même choses écrit en purebasic, histoire qu'on arrête les préjugés, je sais pas si les perfs sont exactement les mêmes, mais la différence doit être négligeable.

Parce que conseiller le C++ quand on ne connait pas ce que fait le purebasic c'est un peu idiot. Je veux rajouter de plus que coder des choses en C++ prend plus de temps et sont plus difficile à coder qu'en purebasic, déjà qu'on part sur un projet de au moins 3 mois pour une demo potable (et je suis optimiste), faudrait pas en plus qu'on rajoute 3 mois de plus parce qu'on utilise un langage 'compliqué' oui le C++ c'est 'compliqué' et je suis partisan de la théorie que plus un projet dur longtemps plus il a des raisons d'être abandonner !

Mais on peut continuer ce débat sur le purebasic en section programmation sur le sujet de blendman, sa sera mieux.

Et longue vie à 3Arks

onilink_ a écrit:

Lol pour dofus, marrante l'anecdote :p

Oui, mais c'est vrai en plus. C'est Anthony, l'un des 3 boss d'Ankama qui m'avait expliqué ça il y a 5 ans.
Ce qui est marrant, c'est qu'on me fait souvent ce genre de remarque : pourquoi tu ne fais pas un jeu en 3D plutôt qu'en 2D? pourquoi tu utilises blender et pas 3Dsmax ? Pourquoi tu utilises purebasic et pas du c++ ?

[quote]Sinon ouai, faut utiliser un langage avec lequel on ce sent bien pour développer un jv.[quote]En ce qui me concerne, ça va même plus loin : je préfère utiliser un outil moins performant (comme GM à une certaine époque), et être certain de terminer un projet plutôt que de me lancer dans un projet avec un outil que je maitriserai pas et voir le projet s'arrêter avant la fin.

Citation :

Pis une chose importante a savoir, c'est que qq soit le langage que t'utilise, une fois que t'auras finis ton jeu, ben c'est con de le dire mais il seras FINI, et
rien ne t'empêche de migrer sous un autre langage pour en faire un version améliorée (ce qui est beaucoup plus simple que de refaire un projet 0, étant donné qu'il faut juste programmer, tout le reste est fait !)

Exactement. LE but d'un projet est qu'il soit terminé, d'aller au bout.
Pas qu'il soit fait avec tel soft de 3D ou tel langage .

De toute façon, je pense qu'avec PB, on aura de meilleures performances qu'avec GM, donc, on aura au moins gagner ça au change .
Et niveau dev, je suis très surpris, car l'apprentissage est vraiment très rapide (pour moi).

Citation :

En tout cas bonne chance

merci

robotic76 a écrit:

tu pourras essayer SFML pour la 2d, c'est une sorte de SDL destinée au C++, les performances sont meilleures aussi.

j'avais essayé de tester la SFML, mais impossible de lancer quoique ce soit avec. J'ai laissé tomber du coup.

ombre a écrit:

Je poste ce message juste pour dire que le purebasic me gave parce qu'à chaque fois que je présente le langage les gens restent fixer sur le mot 'basic'.

Ne t'inquiètes pas c'est une réaction normale. J'ai la même lorsque je dis à des infographistes pros que je bosse avec blender .

Citation :

Je veux rajouter de plus que coder des choses en C++ prend plus de temps et sont plus difficile à coder qu'en purebasic, déjà qu'on part sur un projet de au moins 3 mois pour une demo potable (et je suis optimiste), faudrait pas en plus qu'on rajoute 3 mois de plus parce qu'on utilise un langage 'compliqué' oui le C++ c'est 'compliqué' et je suis partisan de la théorie que plus un projet dur longtemps plus il a des raisons d'être abandonner !

Et encore, 3 mois en plus, c'est léger. Personnellement, je pense qu'il faudrait ajouter facilement 6 mois à 1 an, car personnellement, il faudrait déjà ce temps-là pour l'apprentissage du c++.
Avec pb, en quelques semaines, on peut déjà bien se débrouiller.

Regarde le moteur graphique que j'ai fait en quelques jours alors qu'en même temps j'apprenais le pb (bon, j'ai été sacrément aidé par Comtois, c'est vrai ).

voici un screenshot réalisé en quelques jours d'apprentissage avec pb :


J'ai déjà ça d'intégré (aidé par Comtois) :
- affichage des sprites, avec le centre
- déplacement du personnage
- création d'un "view", avec scrolling attaché au personnage
- background tiled
- affichage uniquement de ce qui est visible dans la view (en gros : collision entre écran et sprite)
- depth (tri des image suivant l'affichage)
- position et sprite aléatoires pour les sprites arbre et sol
- chargement/sauvegarde des positions si besoin (création de .map)
- option fullscreen/mode fenêtre
- détection de la résolution de l'écran du joueur (pas activé, mais ok)
- et d'autres petites choses.

Et le scrolling est superbe, fluide, pas de déchirure comme avec GM ou de saccades

Citation :

Et longue vie à 3Arks

je confirme

Ah ben content que ça avance bien. En tout cas le rendu est très beau, j'ai hâte de voir ce que ça donneras en plein jeu :p

onilink_ a écrit:

Ah ben content que ça avance bien. En tout cas le rendu est très beau, j'ai hâte de voir ce que ça donneras en plein jeu :p

c'est vrai que le rendu est sympa et fluide .
Comparé à GM, c'est déjà bien mieux, rien que pour ça, je suis content .