[Jey]

Salut tout le monde,

je voulais faire un petit sondage, auprès de ceux qui connaissent vraiment l'éditeur du jeu nwn, et donc qui savent de quoi ils parlent. (c'est pas de la discrimination méchante pour le plaisir, c'est juste que c'est un sondage sérieux lol). Enfin voilà, en fait c'est un copier-coller d'un message à moi sur un autre forum, mais ici y a aussi pas mal de connaisseurs, alors j'en profite. :-)

Donc en gros, j'aurais pour vous diverses questions. Ca concerne principalement le design général de l'éditeur, pas les spécificités à nwn, genre ça peut autant être l'ergonomie de l'interface graphique de l'éditeur (bonne ou mauvaises selon vous sur certains points), que les concepts utilisés (par exemple le système d'évènement, si vous le trouvez génial; si au contraire vous auriez intégré le script autrement, par exemple plus au niveau du monde qu'au niveau de chaque objet; si vous avez des avis mitigés, que tel chose est bien mais a des limites).
Voilà, n'hésitez pas à donner des détails, ou des exemples de trucs qu'un jour vous aviez voulu faire, mais soit était impossible, ou alors particulièrement long, difficile, rebutant, etc.

Les questions sont du genre:

1/ Quelles fonctionnalités de l'éditeur trouvez-vous particulièrement puissantes?
1bis/ Et au contraire, qu'est-ce qui est vraiment faiblard?

2/ Quelles fonctionnalités trouvez-vous particulièrement facile?
2bis/ Qu'est-ce qui est au contraire mal foutu/chiant à faire/.etc.?

3/ Qu'aimez-vous dans l'éditeur, dans le langage de script, etc.

4/ Qu'auriez-vous aimé différent, ou amélioré?

5/ Que détestez-vous?

6/ Vous devriez faire le design d'un tel éditeur pour un jeu, que voudriez-vous? Des suggestions, avis?

7/ N'hésitez-pas à inventer toute question qui donnerait votre avis, etc. et à en poster les réponses ici.

Merci. :-)

[Garrath]

Alors moi je vais juste parler de la partie que j'utilise le script

L'editeur de script est moyennement ergonomique d'ailleurs je l'utilise presque pas
Par ailleurs la compilation lance a partir de Aurora de tous les scripts a tendance a etre bugge... des fois il sort pas d'erreur alors qu'en fait il y en a dans certain script ... c'est super enervant car du coup tu testes et rien n'a change pour la bonne et simple raison que le compilateur n'a pas compile ton script (vu qu'il y avait une erreur) et donc tu as toujours l'ancienne version. Et cela arrive tres souvent.
Des fois aussi il sort des erreurs alors qu'il n'y en a pas... regulierement il me sort des erreurs sur des include comme quoi ils n'ont pas de main ...
Donc maintenant je fais un truc simple, je vire tous les fichiers ncs avant une recompile complete du module (mais meme comme ca j'arrive encore a avoir des surprises )

Alors pourquoi je n'utilise pas l'editeur de texte de Aurora ben parce qu'il est assez peu ergonomique je prefere utilise UltraEdit par exemple (j'ai cree des macros pour pouvoir ouvrir les include en double cliquant sur le nom de l'include par exemple , il ne connait pas la tabulation aussi (ce que je trouve hyper chiant), on peut pas lui coller un fichier d'aide (avec ultra edit j'ouvre le fichier d'aide du Lexicon ) ) et aussi parce qu'il est super lent pour sortir ... J'attends facilement 30 s quand je quitte l'editeur de texte de Aurora avant de recuperer la main sur Aurora (pourtant j'ai qu'un petit Prescott 3.2 avec 1 Go de Ram en dual channel!!!)
D'ailleurs ce temps d'attente est plus reduit (voir inexistant) quand je suis arrive sur un script en passant soit par les evenements d'un objet quelquonque ou en passant par l'editeur de dialogue...

Bon apres dans le langage script, il manque pas mal de trucs ... une fonction permettant de changer le prix d'un item, fonction permettant de changer le nom d'un PJ etc... mais bon on fait avec



Sinon un autre petit trucs que je trouve chiant qui n'est pas lie aux scripts, c la mise a jour de la palette.
Exemple le CEP. Nous avons commence a creer notre module avec le CEP et forcement le cep.tlk en anglais. Depuis j'ai recupere une partie de cep en français et j'en ai traduit quelqu'uns moi meme. Donc dans la palette ils apparraissent bien en français par contre un objet qui a ete traduit en français dans la palette apparait toujours avec son nom anglais etc dans les zones s'il y ete pose avant la mise en place de ce nouveau tlk.
Et la on a possibilite en lancant une mise a jour sur tout le module de le faire changer. C'est une operation assez longue (plus d'une heure chez nous) et en plus ca ne prends qu'un seul objet a la fois... donc ca c lourd
(Bon peut-etre qu'on le fait pas bien mais si vous avez un moyen de le faire sur tous les objets d'un seul coup moi je suis preneur)

Autre chose aussi c le choix de la langue par defaut! Nous on est en français ben alors pourquoi lorsqu'un PJ feminin arrive et que cela soit pour une description ou un dialogue si la zone texte n'est pas renseignee pour le feminin il me prend a chaque fois le texte Anglais! et pas le texte français Masculin! (alors peut etre que la aussi on utilise mal)


EDIT : En terme de script il manque 2-3 trucs... Pas des fonctions qui manquent mais plutot des concepts qui manque au langage
- La possibilite de passer des parametres directement au main on est oblige de passer par des locales c chiant et ca complique pour rien le code
- une meilleure gestion des fonctions qui sont dans les bibliotheques. Je veux dire par la pas une copie de l'include dans le code du source avec le main comme c'est fait actuellement, mais juste l'utilisation des fonctions utilises (comme en C quoi...) ce qui donnerait des ncs plus petit. En gros un linkage en fait... Si en plus il pouvait etre dynamique ca serait royal mais bon
- des tableaux... aller ok pas de pointeurs ca reste du script qui doit etre simple mais bon des tableaux quand meme.
- Une veritable gestion des evenements et non ce qui est fait actuellement. Actuellement par exemple si vous voulez modifier un evenement on vous dit d'utiliser le On_User_Define. Ok mais si c'est deja un evenement predefini on passe d'abord par le code de l'evenement predefini et ensuite on appel le On_user_define et on fait le code prevu dedans. C ni plus ni moins qu'un ExecuteScript avec un positionnement d'entier pour simuler un evenement.
- une surcharge pour les fonctions etc... ce qui eviterait d'avoir 15 fonctions avec des noms differents alors qu'elles font la meme chose mais c'est juste qu'elles ont pas toujours les memes parametres...
- Aller peut etre des vrais objets mais je pense que cela compliquerait pas mal pour bcq de monde...

[Kétil Dimzad]

Pour moi, le plus gros défaut c'est l'impossibilité de pouvoir ouvrir plusieurs fenêtres en même temps.

De même, ça serait bien d'avoir de petits logiciels annexes pour la fabrication d'objets, dialogues et scripts ( meme si ça existe pour les scripts c'est pas de base donc... )

Une doc de référence avec tous les includes et ce qu'ils font.

Une doc de référence avec tous les sons, les effets lumineux etc......

La possibilité de fixer librement les prix des items, le niveau d'utilisation sans être obliger de ce baser sur les prix des items, la possibilité de changer les noms des objets ( même si par bidouille on peut, on peut pas par script mais Garrath en a parlé )

Si j'ai d'autres remarques je le noterai

[Sherazade]

Coté script des vrais objets et des tableaux, comme le dit Garrath, une gestion intégrée de DB externe moins médiocre que la DB Bioware actuelle, MySQL par exemple , moins de fonctions codées en dur, plus de souplesse sur les races / classes personnalisées.

Coté mapping, la possibilité de mélanger facilement des éléments de tilesets, et ne pas avoir des tilesets figés. Là, c'est la croix et la bannière pour fabriquer ses propres haks de tilesets.

Un Aurora qui soit moins lent, même avec une machine de combat (PIV-3.4Ghz, 2 Go de RAM), il me faut 1h30 pour compiler un module complet...

Quelques outils externes utiles comme un compilateur, un éditeur de dialogues, un éditeur de créatures / objets / placeables, bref, des outils qui ne nécessitent pas forcement le lancement d'Aurora et qui accélérerait probablement le schmilblick. Un éditeur 3D se serait parfait aussi, mais il ne faut pas rêver, il faudra se "contenter" de GMax. De toute façon, je suis une bille en 3D, donc je ne suis même pas sûre que je m'en servirais .

Il y aurait plein d'autres trucs, mais c'est ce qui me vient à l'esprit en premier !

[Mickey974]

d'accord avec tout ce qui a été énuméré et certain autres trucs qui sont ULTRA gênant comme :

- la non maîtrise de l'axe des Z. Sous l'éditeur on peut aller de -10 à 100. Cet axe des Z ne peut pas être scripté.
- L'aspect figé de la 3d. Aucun objet placable placé sur une carte ne pourra être bougé. Il faudra le détruire puis le recréer. Ce point est vraiment une gageure je trouve.
- Pas d'inclinaison possible. On est sensé être dans le monde de la 3d, donc un objet se définit par ses coordonnées un vecteur directionnel, mais également un vecteur d'inclinaison. Nada !
- La solution walkmesh et pathfinding mixé. C'est exécrable à l'usage. Walkesm est ce qui permet de dire de quelle nature est le terrain et le code pathfinding inclus dans le tileset permet de déterminer quel route la plus courte choisir. Sous l'éditeur on ne voit jamais rien et on a aucun contrôle de ses aspects !!!! Pourtant si important !!!!
- coté script : l'impossibilité de faire appel à des Dll externes comme dans tous langages scripts qui se respectent.
- un base de données. Pour ma part, il n'y a pas de base de données dans la 1.65 en standard. Ne me parlez pas du truc de bioware. Une base de données qui se respectent suit un standard. Peut on utiliser du SQL avec la base de données de Bioware ? Non ! Donc ce n'est pas une base de données.
- compilation conditionnelle. Pourtant si facile a intégrer dans un langage de script surtout le langage d'Aurora.
- un editeur customisable, permettant l'intégration d'outil externe. Mais bon la je rêve.
- des fenêtres qui soient déplacables et non pas figées. on peut juste les redimensionner mais on ne peut pas par exemple, mettre la fenêtre qui affiche la carte en réduction pour faire de la place aux autres.
- Possibilitée de jouer des fichiers biks directement par script

[Garrath]

Citation :

Publié par Kétil Dimzad

Pour moi, le plus gros défaut c'est l'impossibilité de pouvoir ouvrir plusieurs fenêtres en même temps.

Yep c aussi pour ca que j'utilise un editeur externe pour le script ... ce qui me permet de tj visualiser les objets leur tag etc... dans Aurora

[Kétil Dimzad]

Autre truc important, la possibilité d'organiser toute la palette personnalisée de tous les objets à loisir. En créant des branches, en en renommant d'autre. P't1 ça serait bien cool ça ^^

[Jabbal'H]

Pareil qu'au dessus mais avec les script, pouvoir creer des branches pour y mettre des script, je trouve horrible d'avoir 1000 scripts à la suite.

[Heziva]

Tout a fait hors sujet mais..... pourquoi cette question?

Pour le 2bis je ferais appel a un vieux poste de Mickey.... il indiquait une astuce pour ouvrir rapidement un module. Il s'agissait de faire croire a l'éditeur qu'il s'était mal fermé la dernière fois et d'utiliser l'option "récupérer modeule".
Pourquoi serait il plus rapide de récuperrer que d'ouvrir un module? L'ouverture simple ferait elle des vérifications inutiles?

En dehors de cela, je n'utilise que le coté "scriptes".... et d'autres ont bien résumé les critiques que je pourrais avancer.

Enfin, j'aimerais tout de meme rappeler que neverwinter est peut être le seul jeu du genre a proposer une si grande customisation. L'outil a certes ses défaults, mais nous permet déja de faire beaucoup!
Par ailleurs, je salut la relative simplicité du langage nwscripte. Pour avoir éssayé de créer des maps a starcraft, puis a warcraft3 et enfin a Morrowind, je salut bien bas les développers de Bioware!

[Kétil Dimzad]

Attend Heziva , l'éditeur de starcraft est quand même super simple...C'est pas comparable avec Aurora...

[Sherazade]

Citation :

Publié par Heziva

Pourquoi serait il plus rapide de récuperrer que d'ouvrir un module? L'ouverture simple ferait elle des vérifications inutiles?

Tout simplement car lors d'une ouverture normale, Aurora décompacte l'ensemble du .mod en l'ensemble de tous les fichiers compasant le module, les .nss, .git, .are, .utp, etc... Bref, des milliers voire dizaines de milliers de fichiers pour les gros modules. Donc, tout ceci prend du temps, une ouverture comme le fait Mickey contourne cette ouverture, en conservant le répertoire /temp0 en général, dans lequel se trouve l'ensemble de ces fichiers lorsqu'Aurora est ouvert .

[Taern]

Pareil qu'Heziva.
D'ailleurs, à bien y réfléchir, les améliorations qui rentrent vraiment dans le cadre du design du toolset sont pas évidentes à trouver.

- une interface multi-fenêtre, avec possibilité d'alterner entre etc. (NWN2 )
- passage de paramètres dans un script de dialogue (NWN2 )
- possibilité d'ouvrir plusieurs modules en même temps, de faire des transferts entre les deux
- une plus grande liberté dans la définition des paramètres des objets (prix, niveau mini etc.)
- la possibilité de modifier la taille des objets/créatures
- globalement pour le langage de script, un plus grand contrôle sur les propriétés des objets (noms, description, position etc.) et plus de flexibilité en général : semblants de tableaux, pointeurs et classes (sans non plus demander du C++).

Et évidemment un toolset plus rapide, plus performant, plus flexible pour ce qui est de l'organisation de l'espace de travail (barres d'outils, modification des palettes, etc.), et avec une option "Test module" en cerise sur le gâteau

Quant à une vraie base de données, à l'accessibilité des translations et rotations manquantes, aux éditeurs de classes/races/sorts/etc., ceux-ci seraient des plus extraordinaires mais malheureusement ils ne rentrent pas dans le cahier des charges du jeu et du toolset

[Simkim]

Tu as oublié un (NWN2 ) à la fin de cette phrase

Citation :

- la possibilité de modifier la taille des objets/créatures

Pour les objets je ne sais pas, mais il me semble que ça a été confirmé pour les créatures. A cause de certains problèmes liés aux animations, la différence de taille sera limitée, mais je crois qu'ils avaient dit quelque chose comme +-10%.

[Heziva]

Citation :

Publié par Kétil Dimzad

Attend Heziva , l'éditeur de starcraft est quand même super simple...C'est pas comparable avec Aurora...

Oui certes il est super simple..... lorsque tu veux faire une carte de base!!!
Peut être étais je un peu jeune lorsque j'ai voulu creer des cartes de starcraft , mais j'ai souvenir d'une tres moindre flexibilité. Je te parle bien de la création de ces maps "personnalisées" avec tout plein de scriptes dessus

ps: a la réflexion..... 95 starcraft? oué c'est ca je devais avoir 12-13 ans lorsque je m'y suis attelé! possible que mon incompréhension vienne de la

[Jey]

Salut,

shuis content de voir pleins de réponses.
Malheureusement je suis pressé là, j'ai juste fait un tour à la fac pour voir mes mails/réponses, etc. J'ai juste lu le sujet en diago. Mais vos réponses ont l'air super intéressantes et je reviendrai lundi pour les lire plus attentivement. Et n'hésitez pas à rajouter des trucs, des idées qui vous sont venus, etc. sur l'ergonomie du toolset, du langage, des suggestions sur "ce que vous auriez fait" (sans prendre en compte le comment, juste la finalité du "ce serait bien si"), etc.

Je répondrai sûrement à la question du "pourquoi je demande ça" dans quelques temps, ne serait-ce que pour avoir de nvelles réponses plus précises.
Allez bye les gens. Et merci encore (et d'avance pour la suite aussi lol).

[Jey]

Coucou,

j'avais promis, et je reviens, même si plus tard que prévu (mais bon, est-on à qques jours près?). J'explique donc le pourquoi du comment de ma question en vous copiant encore un message qui explique ailleurs la même chose lol:

__________________
Saluts les zoulous,

bon, j'avais promis de revenir sur ce sujet pour l'expliquer un peu.
Je participe actuellement au jeu d'un développement libre nommé "Projet Univers" (www.punivers.net). Pour situer vite fait le jeu, c'est un jeu de simulation spatiale: je dis simulation, non arcade, car même si les jeux de simu spatiales ne sont pas complexes comme des jeux de simu d'avions à la Flight Sim, ce ne sont pas pour autant des bêtes shoot'em ups ds l'espace pour moi. En gros, on est plusieurs à avoir été (voire à être tjrs) des fans et des gros joueurs des jeux X-Wing vs Tie Fighter et X-Wing Alliance. Malheureusement après ce dernier Lucas a arrêté de sortir des simus pour ne plus sortir que des jeux arcades.

Bon voilà, le projet en gros.
Là où j'en viens, c'est que perso, je bosse actuellement sur une partie toolset, dont j'ai proposé le nom depuis adopté "Space Theater", car c'est un créateur de Space Opéra! En fait le jeu va se présenter assez similairement à nwn, du fait qu'on va proposer une campagne de base, mais qu'on va en faire -- grâce au Space Theater -- une boîte à création de campagne, aussi bien, et je l'espère mieux que celle de nwn!

Bon, c'est pas du tt un jdr, mais le principe reste le même.
En fait, quand je dis que je bosse sur cela, c'est d'autant plus vrai que j'en ai fait ma thèse de Master: pendant 6 mois, je ne vais faire que cela, bosser que sur ça.

Bon, j'aimerais un avis sur des documents que j'ai écrit. Alors ce sont des brouillons, sûrement pleins de fautes, autant de conceptions que de français, à peine relus, et en gros, chacun d'eux a été écrits en une ou 2 nuits pour la plus grosse partie. Ce sont donc des snapshots de ma pensée, qui a peut-être même évoluée depuis.
N'empêche je veux votre avis, si vous acceptez de prendre un peu de tps pr les lire.

Vaut mieux lire dans l'ordre ftp://ftp2.zemarmot.net/zemarmot/Spa...design0.02.pdf, qui est le design général de l'éditeur. Je n'ai pas encore ajouté toutes vos idées, que j'ai pourtant notées, pour celles qui correspondent à mon travail, car ce document commence à dater.
Ceux qui font de la conception de modules ds nwn ne seront sûrement pas dépaysés, même si des fois je modifie (en mieux d'après moi, à vous de me dire si vous êtes d'accord lol) ou ajoute certains concepts.

Puis la seconde partie à lire, et là, c'est presque (sûrement même) l'avis le plus important que j'attends, c'est le langage de script que j'ai imaginé la nuit dernière [non y a 3-4 nuits maintenant, depuis la copie de ce message lol], car je n'arrivais pas à dormir, cette idée a poppé dans ma tête, alors je me suis levé ds la nuit, ai allumé mon ordi, et ai écrit, pour me recoucher heureux d'avoir mis tt ça sur papier (enfin sur ordi lol) qd le soleil était déjà levé.
Pourquoi j'attends vraiment un avis dessus? Car le design de syntaxe que j'ai créé est tout à fait inhabituelle, et vraiment loufoque. Cependant, je pense que c'est absolument faisable. On m'a déjà donné des avis dessus, et j'aimerais bien savoir le votre, autant celui des non-programmeurs (savoir si vous trouvez que ce serait un langage absolument idéal pour newbee, ou bien si au contraire, vous seriez encore plus déconcerté qu'un langage classique comme le nwscript: en gros, sachant que pr un module, vous y passeriez du tps, vous préféreriez le passer sur le nwscript ou mon script?) que les programmeurs (savoir si vous seriez dépaysés, si vous trouvez ça risible, si jamais au grand jamais en tant que programmeurs, vous écririez des scripts sur un tel "truc" lol).

En gros, donnez moi de vrais avis objectifs, je veux réellement savoir ce que vous pensez, pas que vous me fassiez plaisir: si vous trouvez ça nul, risible, merdique, idiot, dites le moi; si vous trouvez ça génial, bien, moyen, pas bien, dites le moi aussi. Et donnez moi aussi si vous pouvez des raisons, des idées, des ajouts, des opinions, des sentiments, tout quoi.
Eventuellement si vous êtes programmeurs, n'hésitez pas à me dire si vous voyez des limitations, même si je demande pas du tout un avis technique, donc n'ayez pas peur si vous n'êtes pas capable de répondre qd même.
(j'ai d'ailleurs moi-même perçu déjà un problème ds ma syntaxe qt aux instructions composées imbriquées, mais bon, j'essaierais de régler ça, c'est pas grave ça: j'ai un long boulot de design à faire derrière de ttes façons [et puis en fait mes idées ont déjà évolués depuis ce document, et j'ai ajouté, et modifié plusieurs trucs du docs, mais on s'en fout, c'est la philosophie du truc que je veux montrer qui est important là, pas l'écriture technique non commencée])

Pour ceux qui me demandent si ça peut être aussi puissant que le nwscript, ou si ça risque d'être plus limité, je réponds qu'il n'y a aucun problème de ce côté là. Si j'implémente une telle syntaxe, elle aura la possibilité une fois terminée et implémentée d'être aussi puissante que le nwscript... voire peut-être plus si j'arrive à suivre les conseils qu'on me donne pour ne pas retomber dans les pièges dans lesquels ils sont tombés eux-même.

Mais je veux savoir si cette syntaxe plaît, aux néophytes non programmeurs, autant qu'aux habitués des langages classiques.
Allez j'arrête de parler, je donne le lien et j'attends les avis:
ftp://ftp2.zemarmot.net/zemarmot/spa...esign-v0.1.pdf

Edit: j'y pense, je voulais dire un truc, mais j'ai oublié sur le coup:
Sherazade, tu parles d'un compilateur externe, mais je sais qu'il en existe un en ligne de commande fait par un gars, et qui marche... mais surtout je me rappelle que ce même gars avait dit que son compilo ne servait plus à rien depuis que Bioware en avait fourni un officiel (aussi non graphique en ligne de commande) à partir de je-sais-plus quelle version.
Il va de soi que ces compilo (autant le officiel que le non) sont bien plus rapides qu'en utilisant Aurora. Je peux pas vérifier (sur la version Linux a été viré tout ce qui consiste en la création de modules, donc le toolset, etc. malheureusement. Et je n'ai pas encore fait les bidouillages pour l'install roots de la version win du toolset... mais c'est prévu... un jour lol), mais si je me rappelle, on trouvait le compilateur externe dans un répertoire genre utils/ ou qqch comme ça... à vérifier dans votre rép racine du jeu. :-)

Je pourrais éventuellement essayer de retrouver le lien si vous en avez besoin et si vous demandez. :-)

[Mickey974]

Moi j'ai quelques questions.

J'ai regardé ton site ... et ... le projet à l'air ambitieux !

Bien.

Vous démarrez à partir d'où ? De zéro , ou alors vous avez déjà un moteur 3d, un moteur de gestion des collisions, un moteur pathfinding, (éventuellement) un moteur IA, et un moteur "gestion multijoueurs" ?

Car à mon humble avis ... avant de commencer à écrire un éditeur pour créer des modules (comme Aurora) avec un langage script et tout le tremblement, il faut commencer par créer le noyau du jeu. Enfin c'est mon avis.

Alors ? Avez vous déjà le noyau du jeu fait ?

[Taern]

Bravo pour ton projet Jey

J'ai pas lu tous les documents (y'en a carrément pleins ) mais en tout cas ça a l'air béton. Ca sens le pro à plein nez, si si

Pour ce qui est de ton language de script, c'est une idée intéressante et tu semble avoir bien exploré ce qu'elle offre.
L'aspect "accessible à tous" est vraiment séduisant, mais ... moi je suis pas tout à fait convaincu. C'est vrai qu'en théorie tu peux atteindre la même puissance que le nwscript voir un peu plus, mais les exemples m'ont donné l'impression que les choses deviennent plutôt confuses quand on fait des trucs un peu poussés.
Bon j'avoue j'ai pas lu ton pdf intégralement, donc c'est ptêtre pour ça que ça me semblait un peu flou. Et puis, après tout, un truc du genre while((iVar=(b?iVar+1:iVar-1))){if(iVar<0)continue;iVar++;} c'est pas non plus limpide ! (cet exemple ne veut rien dire, je sais)
Par exemple, à force d'être permissif, le builder lui-même risque de se paumer un peu. Si je dis : Ship attacks EnemyShip with Laser, without fanatism, afterburner.
Ca signifie que le vaisseau va attaquer en utilisant son afterburner, ou justement en ne l'utilisant pas ? (after burner, post combustion en français, est un procédé aéronautique qui consiste à augmenter pendant quelques instants le débit de carburant dans la chambre de combustion d'un réacteur, afin de monter la température dans celui-ci, ainsi qu'à modifier la géométrie de la bouche de sortie du réacteur afin d'offrir un diamètre plus exigu de sortie au gaz, tout ceci dans le but d'augmenter la puissance motrice fournie à l'appareil propulsé, oui j'étale ma science )

Enfin bref, tout ça pour dire que je trouve que dans l'ensemble c'est une très bonne initiative. Je ne suis par contre pas sûr qu'on puisse atteindre la puissance et la flexibilité d'un language de programmation classique, pour des raisons de clarté, mais ceci est largement contrebalancé par l'accessibilité du concept. Et puis, ça reste un projet amateur non ? Il n'est peut être pas idéal de viser aussi haut qu'un jeu comme NWN, ne serait-ce que pour le language de script

[Garrath]

j'ai pas lu encore...

Mais sinon un truc qui manque sous aurora... c'est de pouvoir mettre des script et des evenement sur les items...

[mcferson]

Citation :

Publié par Mickey974

- coté script : l'impossibilité de faire appel à des Dll externes comme dans tous langages scripts qui se respectent.
- un base de données. Pour ma part, il n'y a pas de base de données dans la 1.65 en standard. Ne me parlez pas du truc de bioware. Une base de données qui se respectent suit un standard. Peut on utiliser du SQL avec la base de données de Bioware ? Non ! Donc ce n'est pas une base de données.

1) Le langage de script de Aurora n'est pas un langage de script mais une variante du langage de programmation C/C++
2) SQL est un DES langages de BDD qui peuvent exister. Ce n'est qu'un standard, rien n'oblige au SQL pour une base de donnée. C'est juste par soucis de compatibilité, le SQL comme standard. Si Aurora en a rien à foutre d'être compatible, c'est son problème, mais ça reste toujours une base de données.

Sinon, pour ma part je regrette la trop grande complexité du langage en question, parce que sans doc ou manuel c'est Lourd à MORT ! même avec le cours de script pour les quiches, y a des tonnes de fonction non énoncées en six leçons.
De plus, je regrette encore plus la limitation d'utilisation des Tilesets dans cet éditeur : impossible de mettre un château dans la campagne ou de simuler un parc dans une ville ! Choses portant réalisée dans les campagnes du jeu par les devs. Faudrait peut-être qu'ils nous expliquent comment on fait ou qu'ils nous débloquent la catégorisation fermée des tilesets. Moi, je veux mettre des palmier dans ma campagne !!!!!!! et un Gros manoir au milieu de ma verte prairie !!!!!

[Taern]

Citation :

Publié par mcferson

Choses pourtant réalisées dans les campagnes du jeu par les devs.

Les campagnes du jeu ont été faites par le même toolset qui est livré avec le jeu
Si quelquechose t'intrigue, essaye d'ouvrir le module de campagne dans l'éditeur pour voir comment c'est fait.

[Garrath]

Citation :

Publié par mcferson

1) Le langage de script de Aurora n'est pas un langage de script mais une variante du langage de programmation C/C++
2) SQL est un DES langages de BDD qui peuvent exister. Ce n'est qu'un standard, rien n'oblige au SQL pour une base de donnée. C'est juste par soucis de compatibilité, le SQL comme standard. Si Aurora en a rien à foutre d'être compatible, c'est son problème, mais ça reste toujours une base de données.

Une variante de programmation du C/C++... ben non... je crois pas...c pas non plus exactement du script car en regle general on entend par script un langage non compile...
Mais bon de toutes façons y a rien qui ressemble plus à un langage de prog procedural qu'un autre langage de prog procedural... On pourrait aussi dire que ca ressemble au Pascal...

Ben c le hic... l'avantage des standards c d'etre connu... non? On est content car ca ressemble au C car c facile du coup .... ben c dommage de pas avoir acces un langage plus simple pour acceder aux donnees... Le SQL c'est une norme liee au SGBDR mais bon on a pas forcement besoin d'une SGBDR... une base hierarchique ou reseau aurait pu suffire (surtout que cela a tendance a etre plus rapide quand meme ) mais bon le pb c'est l'interface ...

[Jabbal'H]

je dirais quand meme que pour un néophyte en prog, le language NWNscript est aseez accessible.
Certes il a des limitations, mais bon ca reste tout de même suffisament bien, je ne pense pas qu'on puisse demander l'impossible. Enfin ca reste mon avis.

[Mickey974]

Citation :

Posté par mcferson
1) Le langage de script de Aurora n'est pas un langage de script mais une variante du langage de programmation C/C++
2) SQL est un DES langages de BDD qui peuvent exister. Ce n'est qu'un standard, rien n'oblige au SQL pour une base de donnée. C'est juste par soucis de compatibilité, le SQL comme standard. Si Aurora en a rien à foutre d'être compatible, c'est son problème, mais ça reste toujours une base de données.

Tu es un peu a côté de la plaque là !
Le langage utilisé par bioware à une connotation C/C++, mais sûrement pas une variante du C/C++.
Le SQL est le standard utilisé dans tous les SGBDR. Un SGBDR digne de ce nom qui n'utiliserait ou ne serait pas compatible avec SQL serait mort né. Je veux bien qu'on me dise que ce qu'à fait bioware est un système de fichiers permettant de sauvegarder des informations. Mais, même si ce système n'utilise pas SQL, il n'a pas moins tellement de défaut que son utilisation le rend rédhibitoire. On ne peut pas faire grand chose avec le système de fichier de bioware. En comparaison avec le SQL via NWNX2, c'est carrément le jour et la nuit.

[Jey]

Snif, j'ai pas eu tant d'avis que ça sur mes pdf. Mais merci quand même, pour les quelques qui les ont parcouru, mais aussi pour ceux qui répondent encore à la question intiale du sujet tout de même.

Quelques réponses de ma part:

1/ Mickey974

Pour le projet complet, si tu parles du jeu complet, "Projet Univers", oui on démarre de zéro, ça arrive souvent pour un projet de démarrer de zéro (rarement ils débutent après ).
Ensuite, on est amateur, mais pas idiot totalement non plus . Donc on sait ce qu'on fait, cela signifie.
Peut-être connaîs-tu un peu le monde du logiciel libre, qui n'est pas le monde des programmes commerciaux, ni un monde de joyeux lurons qui ne comprennent rien et veulent faire des "freewares" (car un logiciel libre est tout sauf un freeware, et ne partage quasiment rien avec le concept de freeware, excepté éventuellement la gratuité, et encore... même cette notion est énormément différente). Voilà, donc le logiciel libre, c'est avant tout une philosophie, ainsi qu'une organisation économique, autant que philosophique (oui encore) et particulièrement efficace.
Ce que je veux dire, c'est qu'on ne vend pas la peau de l'ours avant de la lui avoir acheté , on ne dit pas "notre jeu sera le meilleur du monde", et on ne dit sûrement pas que notre logiciel finira (et sûrement jamais même, car tel est un des principes de la notion de "libre": un logiciel n'est jamais fini, d'où leur efficacité par rapport à nombre de logiciels commerciaux) .
Je concluerais donc sur tes conseils en disant qu'heureusement pour nous tous, oui Linus Torvald a commencé de zéro (ou presque, bien que basé sur un Unix-like...) pour construire son noyau Linux, oui Stallman a commencé aussi de zéro pour créer GNU (et ainsi ils se sont associés pour nous fournir probablement le meilleur système d'exploitation GNU/Linux).

Voilà voilà. Donc oui, on commence de zéro, et on est débutant. Mais on en est fier. ;-)
- Pour te répondre à d'autres questions, l'une de nos décisions est tout de même d'utiliser le moteur 3D libre Ogre3D (très puissant à ce qu'on dit, et j'ai vu qques jolis trucs en sortir).
- Les collisions, je sais pas trop, je pense que Ogre3D doit gérer déjà des trucs du genre, mais je t'avoue n'être pas spécialiste en 3D (et bien que je vais bientôt bosser sur Ogre3D, et que je trouve que le graphisme est un domaine très intéressant, c'est pas celui qui m'intéresse le plus, mais plutôt l'IA.).
- Le pathfinding, j'ai fait pas mal de recherches dessus, ainsi que quelques tests d'algorithmes. Cependant, j'en suis aussi venu à la conclusion que pour notre type de jeu, un bon pathfinding est très accessoire: ben oui, dans l'espace, t'as peu d'obstacle, et t'as pas besoin d'un pathfinding de fou pour les éviter! Il faut savoir qu'on dit que les jeux de rôles sont un des types de jeu les plus complexes et complets à créer. Nous ne faisons pas un jeu de rôle en l'occurence, bien qu'il m'intéresserait un jour d'en faire un. En attendant, éviter du pathfinding de fou permet d'épargner le processeur: tant mieux, on pourra développer une IA plus performante. ;-)
- Le moteur IA, je m'occuperais bien de ça avec les autres... :-) Et même peut-être auras-tu compris que l'éditeur et le langage de scripts sont très liés à l'IA. :-)
- Enfin le multi: ben je pense que même si -- par curiosité et un peu d'intérêt -- j'y jetterai un oeil, c'est encore moins ma priorité que la graphisme, car je suis un maudit du réseau (au sens propre, je crois qu'on a dû me jeter une malédiction à ma naissance). Cependant, il n'en ressort pas moins que c'est évidemment tout de même une de nos priorités finale, car notre jeu est orienté solo et réseau! Mais je fais aussi confiance à tous ceux qui bossent et bosseront avec moi (j'ai dit qu'on est dans la philosophie libre?).

Pour finir, je dirais que les autres bibliothèques utiles, pour tellement de choses, nous les utilisons déjà par dizaine (ai-je dit comment fonctionnait le monde du libre? ). Donc t'inquiètes pô, on n'est pas entièrement stupide, on commence avec les bonnes bases.

Enfin dernier truc: je ne suis absolument pas d'accord avec ta conception du noyau du jeu, en tous cas pas par rapport avec notre jeu. Au contraire, l'éditeur, les scripts, et "tout le tremblement" font selon moi grandement partie du noyau du jeu: tout comme le font partie l'éditeur Aurora de nwn pour ce dernier!
Un tel jeu de type modulaire repose sur la création externe, et est "dirigé par les données", non "dirigé par le code". Donc oui, c'est pour moi une des bases, et même s'il va de soi qu'un moteur minimal (dérivé d'Ogre3D comme j'ai dit) sera nécessaire aussi, de même ce dernier ne serait rien sans mon éditeur. Malheureusement, j'ai beau être génialement génial (quoi? Comment pas vrai? ), je ne peux pas tout faire, et les autres programmeurs de l'équipe ont bcp de boulot. Contrairement à moi, ils n'ont pas eu la chance d'en faire un projet universitaire. Donc il faut leur laisser le temps.
Donc je fais ma part déjà, on verra après. On n'est pas un jeu commercial, on n'est pas aux pièces.

Je tiens à dire aussi que mes programmes seront probablement très modulaires, et que même si nous devions par malchance ne jamais pouvoir avancer le jeu à un stade suffisamment jouable, je serais tout de même heureux que des parties de mon travail puisse (et soit) tout même être réutilisé ultérieurement par d'autres projets libres -- puisque c'est ainsi que marche le monde du libre -- voire des commerciaux. Donc rien que cette idée me conforte dans mon idée de faire ma partie actuelle aussi bonne que possible, quelque soient les autres.

Enfin voilà, malgré ma longue tirade, les rares qui peuvent me connaître ici savent que ce n'est pas du tout que j'étais énervé, ni rien hein. Faut surtout rien prendre mal. C'est juste que c'est ainsi que je m'exprime: en parlant beaucoup, voire trop. Et surtout, j'adore défendre le libre partout, pour promouvoir le mouvement et emmener les gens à changer leur mode de pensée quant à cette révolution! (enfin révolution... c'est une notion qui commence à vieillir, mais tellement inconnu du public)

2/ (oui, seulement )
Taern : je pense que tu peux avoir raison.
Mais justement, je vais tenter de faire en sorte que non. Je pense cependant que pour un vrai langage de programmation (et le but, c'est que c'en sera un malgré les apparences, faut jamais l'oublier :wink: ), tout devient forcément confus quand le raisonnement devient lui-même compliqué. Ce serait surtout lié au raisonnement lui-même donc, plus qu'à la syntaxe: en gros au contenu qu'au contenant. Je sais pas si on peut y faire qqch.
Ensuite, il est vrai que certains orateurs particulièrement doué arrive à mieux expliquer que d'autres des concepts complexes. Je vais essayer de faire en sorte que mon langage soit cet orateur. Mais il n'en arrive pas moins que quand cet orateur en vient à tenter d'expliquer des théories d'Einstein, ben aussi bon soit-il, ça doit être complexe à suivre. ;-)
Pour ton exemple, une telle fonction serait tout simplement mal écrite selon moi: mon langage offre la possibilité de faire des fonctions intuitives, cela ne signifie pas qu'on peut pas mal utiliser ces possibilités. Le fait est que le gars qui écrira la fonction attack devrait penser (par exemple) à faire de ce paramètre optionnel les 2 possibilités au choix "(using afterburner|not using afterburner)".
Il faut juste savoir utiliser intelligemment ce qu'on nous permet. C'est là où est intéressant un langage offrant des libertés (qui peuvent -- comme toute liberté -- être mal utilisée à son avantage, mais qui si bien utilisée sont puissantes).

3/ Pour les quelques derniers posts, je dirais que le nwscript est bien un langage de script (pour Garrath, un langage de script peut tout à fait être compilé, plus ou moins car il y a divers niveaux de compilation...): regarde Lua, Python aussi, Perl, etc.
Ensuite, tout dépend de ce qu'on appelle "langage de script", car en général, on entend par là, "fait pour être utilisé par un utilisateur final", et excepté Lua pour lequel c'est le cas, il est vrai que Python ou Perl par ex sont plus des "scripts pour programmeurs".
Par contre, le nwscript est également bien dédié totalement à être utilisé par un utilisateur final, et vraiment final, car c'est carrêment le client qui va l'utiliser... Pour moi, c'est donc clairement du script.

Mais pour avoir une idée intéressante des différentes notions attachés au terme "script" (qui sont donc presque plus des notions d'utilisations qu'autre chose), une bonne chose est de se rapporter à la définition du wikipedia, qui apporte souvent beaucoup d'aides et est une bonne base de connaissances pour tellement de chose (http://en.wikipedia.org/wiki/Script_language ).

4/ Pour être précis, les développeurs de nwn le qualifie plus exactement comme un "subset" (un sous-ensemble) de C/Java. Et pour être même encore plus précis, quand ils arrivaient à certaines syntaxes exprimées différemment en C et en Java, ils ont pris le partie de choisir la syntaxe Java. Donc finalement, le nwscript est plutôt un sous-ensemble de Java (lui-même dérivé du C de toutes façons). Je l'invente pas, ni ne le déduit, ils le disent dans un article sur l'IA destiné aux programmeurs IA de jeux vidéos et où ils expliquent leurs choix de programmation pour BG et NWN, leurs erreurs, des conseils, etc.

5/ Je concluerais en disant à Jabbal'H que si, il faut demander l'impossible! Du moins, l'utilisateur devant le boulot final, non il ne peut plus, car on ne peut pas reprocher des choix faits quand c'est trop tard. Tant que le dév a fait du bon boulot, c'est du bon boulot: mais pendant la phase de conception, l'idéal est justement de demander l'impossible!
Ce qu'on veut, c'est que l'utilisateur final nous dise ce qu'il veut, ce qu'il rêve... à nous de voir ensuite si c'est réellement possible (tout l'est au final :wink: ) mais aussi si on veut le faire réellement, surtout si ça implique d'autres problèmes, etc.
Donc, ce que je demande là, c'est justement que vous demandiez l'impossible. Ensuite, je m'occuperai de démêler tout ça et d'en faire moi-même une synthèse finale si j'y arrive. :-)
Donc si on peut espérer faire mieux, pourquoi ne pas le tenter?