[leghola]

Pour ce qui est de l'eau, est-ce normal qu'elle apparaisse noir?
Oui ce n'est pas une nappe de pétrole. En fait l'eau est travaillée par deux sous
moteurs, l'un gere la reflection et l'autre la refraction.. Hors, ce qui fait que l'eau est bleue, c'ets le ciel Et j'ai "omis" de rajouter un p'ti ciel bleu..
Donc voila, pas de probleme a l'horizon, le ciel est rajouté et l'eau est désormais toute bleue

NIveau intéractions PJ/PJ il n'y aura pas de nouveauté enorme je pense. Nous n'y avons pas encore pensé réellement... Pourrais tu détailler ta question stp ?

a++
Nico.

[Barti]

Détailler ma question, je vais essayer bien que je ne vois pas trop comment. ^_^

En gros je me demandais comment vous envisagez penser les interactions PJ/PJ.
On pourra que combattre? Marchander? En gros qu'elle influence pourra avoir un PJ sur un autre PJ, et dans quelle mesure les futurs utilisateur d'EYENGUI pourront développer/étendre ces interactions?

Ca me fait d'ailleurs penser à une autre question, quel impact pourra avoir le joueur sur son environnement? Pourra-t-il en avoir un ou le moteur de jeu n'est pas prévu pour ça? Le moteur de jeu permet-il de faire évoluer l'environnement en "temps réel"? (déformations du terrain, destruction d'arbres parce qu'un sort très puissant vient d'être lancé...enfin ce ne sont que des exemples pour illustrer ma question.)

Message supprimé par son auteur.

[leghola]

Hello,

Effectivement EYENGUI est du "100% objet".
En pratique, tu créé un "arbre" ayant un modele particulier. Tu peux lui ajouter des évenements de jeu (se fait tapé, etc.) et pour chaque évenement, un script (une base "template" sera dispo mais chacun pourra écrire les siens.

De plus, tu peux y accrocher autant de caractéristiques que tu souhaites (une certaine quantité est définie "system" et est ajoutée automatiquement).

Ton objet est créé ? yahoo, tu en créés désormais des "instances" : copies de cet objet, possédant toutes ses propriétés/carac/évenements mais qui peut être mis a jour personnellement. Ce sont ces instances que tu places réellement dans le jeu.

Donc en théorie, ce qui t'arrête dans la construction de ton jeu, c'est toi !

Pour lancer EYENGUI nous voulons créer un jeu original (concept sympa, pas inédit mais qui possède assez de nouveautés pour choquer les joueurs habitués). Cela permettra ainsi de voir ce qu'il est possible de faire avec le moteur

a+
NIco

Quand tu parles de ton idee sur les savoirs qui se transmettent, j'ai l'impression de suivre le developpement d'un jeu, et pas d'un editeur de jeu. J'veux dire, le prog doit pouvoir apporter les outils necessaire a la creation de n'importe quel systeme, et non en proposer un deja tout fait, nan?

Sinon au debut tu faisais beaucoup reference a RPGmaker, mais connais tu Game Maker, qui est a mon avis beaucoup plus interressant en terme d'inspiration. (d'ailleurs on peut creer son propre MMORPG avec GM, en fait on peut creer n'importe quelle sorte de jeu, mais la 3D n'est pas son fort c'est vrai)

[leghola]

Hello,

Citation :

Quand tu parles de ton idee sur les savoirs qui se transmettent, j'ai l'impression de suivre le developpement d'un jeu, et pas d'un editeur de jeu. J'veux dire, le prog doit pouvoir apporter les outils necessaire a la creation de n'importe quel systeme, et non en proposer un deja tout fait, nan?

A part "coder" le systeme, je ne vois pas a part créer une usine a gaz comment permettre tout les concepts de jeu. Je ne peux par exemple permettre du tour a tour a la FF ou bien un système de ralentissement a la Prince Of Persia.

Alors ce systeme de savoir a été effectivement développé a l'origine dans le but de l'inclure dans un jeu. Ce sera une option IA disponible sur EYENGUI mais qu'on pourra "désactiver" :-)

Citation :

Sinon au debut tu faisais beaucoup reference a RPGmaker, mais connais tu Game Maker, qui est a mon avis beaucoup interressant en terme d'inspiration. (d'ailleurs on peut creer son propre MMORPG avec GM, en fait on peut creer n'importe quelle sorte de jeu, mais la 3D n'est pas son fort c'est vrai)

Je parle de RPGMaker car il est très connu, mais je n'ai jamais touché a RPGMaker ni a GM même si j'en ai entendu parlé la aussi.

Maintenant, effectivement GM permet de faire tout mais par experience j'ai appris que celui qui peut tout faire n'arrive pas a "bien" faire les choses... Il faut un jour se spécialiser afin de pouvoir etre le plus efficace possible. De part sa conception Eyengui peut très bien être utilisé pour créer un jeu de plateforme ou un RTS mais il faudra démultiplier les fonctions et les sous moteurs pour qu'il puissent accepter toutes les conditions de chaque jeu. Cette démultiplication entrainerait des surcharges de traitements et rendrait ainsi Eyengui moins efficace ...

On pourrait parler de Realmcrafter, de 3d RPGBuilder, etc. J'ai pris RPGMaker comme simple exemple

a++
Nico.

Citation :

Publié par leghola

A part "coder" le systeme, je ne vois pas a part créer une usine a gaz comment permettre tout les concepts de jeu. Je ne peux par exemple permettre du tour a tour a la FF ou bien un système de ralentissement a la Prince Of Persia.

Ben tu le disais toi meme:

Citation :

L'ESS sera très puissant car il sera le coeur du systeme. Vous pourrez completement modifier la facon de jouer, l'IA par elle même, les réactions, méthodes de combat, etc. Le moteur de jeu ne fait qu'execute des scripts soit de type system (non modifiables) soit de type game (modifiables). le type game représentera 98% des scripts...

Donc a priori pas de pb pour inventer son propre systeme, et si ceux proposés par l'editeur sont desactivables comme tu dis, ben y a plus de pb du tout

En tous cas j'ai hate d'essayer le produit fini

Leghola, je rebondis sur la question/gestion des savoirs.
D'après ce que j'ai compris, ton système permettrai d'avoir des savoirs mobiles, qui se propagent, et qui peuvent aussi disparaître ?
Parce que là j'y vois un atout essentiel : terminé les game note et autres BDD faites à l'arrache pour mâcher le travail, le fait qu'un joueur obtienne le savoir X du pnj Y n'est plus une donnée stable, mais fluctuante.
L'idée avancée d'avoir une certaine traçabilité prend alors une nouvelle importance. L'univers informationnel devient mouvant, les joueurs peuvent "mener l'enquête" pour retrouver l'info.

Bref, juste des idées jetées comme ça, mais la question en résumé est :
Le système supportera-t-il des savoirs à la fois (1) mobiles, (2) caduques (comme les arbres ), (3) traçables (de façon limitée, je vois bien le problème d'une traçabilité totale) ?

En tout cas, GG pour ce projet, et pas GG pour les futures nuits blanches!

[leghola]

Hello,

Cette partie savoir est de ma conception et j'ai mis très longtemps a la mettre sur pied (et sur papier).

Des moteurs hyper complexes aux moteur simplistes, j'en ai essayé plusieurs avec des simulations de propagation en 2d très moche mais au combien interressantes.
J'ai meme durant un temps créé un moteur de dialogue permettant a l'IA de composer des réponses par rapport a la detection de mot clés dans une question. (Le joueur posait lui même mot apres mot sa question) : idée abandonnée aux vues de la qualité orthographique du joueur moyen.

Comme toujours une idée c'est bien, la mettre sur papier c'est mieux mais le plus complexe est ensuite de la tester pour la rééquilibrer. Une idée sera toujours magnifique en théorie, mais en pratique....

Bref,

Chaque IA possède un nombre de caractéristiques assez important. L'une d'elle est l'INTELLECT. Cette valeur permet de définir le nombre de connaissances que l'IA est capable de mémoriser.
Prenons un exemple d'une IA avec un INTELLECT à 5. l'IA est ainsi capable de se rappeler de 5 connaissances au maximum.

Il faut aussi bien comprendre que les savoirs sont de 2 types :
- Savoir "Ecrit"
- Savoir "Oral"

Les savoirs écrits sont les savoirs qui vont faire tourner l'histoire du monde et les quêtes, c'est le fer de lance, les savoirs qu'on retrouvera dans des livres, des informations importantes.
Je pense sincèrement pour des besoins purement pratiques qu'un savoir dit écrit doit obligatoirement être référencé dans un support écrit du jeu (un livre de bibliothèque, une stèle, etc.) afin que ce savoir, même si son emplacement peut s'oublier, se disparaisse jamais du jeu.

Imaginez une info importante a retrouver et là il ne faut plus un groupe de joueurs pour tuer un gros monstre mais bien un groupe de joueurs pour chercher l'info dans une bibliothèque avec des dizaines (centaines?) de livres...

Le savoir Oral, lui, ne se retrouvera pas dans un support écrit (même si théoriquement chaque objet du monde est dans la capacité de recevoir des savoirs : arbre, banc, maison, pierre, etc.) Ce type de savoir est généré par les IA suivant leur vision du monde.

Exemples :

• Un joueur payant une IA pour avoir une info va générer un savoir : JOUEUR X est sympa et généreux. Cette info va être véhiculée et le joueur va ainsi etre plus apprécié par les IA ayant eu l'info.
• Un joueur menacant une IA pour avoir une info, ou bien l'attaquant, etc. paf la génération de savoir va se faire en conséquence.

Mais est ce que le roleplay pourrais alors influencer les IA du jeu ???
Je vous laisse l'imaginer....

Donc, pour en revenir à la durée de vie d'une info, elle sera complètement liée à la capacité d'une IA a générer du savoir oral (la fréquence de génération automatique étant relative a une caractéristique 'bavardage') a sa mémoire (Intellect)

Chaque savoir possède un niveau d'importance et ainsi, quand tous les emplacements sont vides, le système efface le savoir d'importance la plus faible pour placer le nouveau. L'importance d'un savoir diminuant avec le temps, même les grands savoirs finiront par disparaitre.

On peut ainsi imaginer que de très anciens joueurs auront des connaissances qui auront été perdues avec le temps...
De plus la façon de jouer influencant directement les IA, les joueurs devront faire plus attention a leur roleplay...

a++
Nico

Il ne te manque plus qu'une feature pour avoir une simulation plus que poussée de l'évolution des infos IRL : un algorithme de... déformation des infos Histoire que rumeurs, légendes urbaines, fausses infos circulent, tout comme les vraies. Partons en sucette : les savoirs écris sont copiables, mais le copiste peut introduire des variations/erreurs contre vérités, chaque savoir obtient une nouvelle feature, sa robustesse (résistance à la déformation)... On va enfin avoir des bibliothécaires/commères/informateurs comme classe à part entière !

[leghola]

Rigole pas trop vite,
On y a pensé...

Effectivement, déformer la vérité est un concept qu'on aurait aimé mettre en place car il apporte un gros plus.... mais cela reste très dangereux.

Je pense qu'on va plutot partir sur une perte partielle du savoir suivant une donnée 'temps en mémoire'... les mots clés composants le savoir et présents dans le texte seront ... oubliés...

Exemple :
Savoir écrit de base "Il y a une stèle devant la grotte des âmes damnées, elle est la clé de la porte de la grotte..."
mots clés : stèle / grotte / âmes damnées / clé / porte

après un peu trop de temps passé en mémoire d'une IA...
savoir redonné a un joueur :
Il y a une stèle devant la grotte des , heu .... mince j'ai zappé ! , elle est la clé de la porte de la grotte... ca c'est certain !"

Et si vraiment ca dure trop longtemps :
Il y a une , arf ! j'ai oublié ! devant la grotte des , heu .... c'est pas vrai, je me rappelle plus ! , elle est la clé de la porte de la grotte... ca c'est certain !"

a++
Nico

[Lyta Alexander]

"Il y a une âme damnée devant la clef qui ouvre la porte"

[Plombier]

Pas de questions pour l'instant mais des encouragements !
(les dernières news de ton blog remontent à mai, j'dois me faire du souci ?)

[leghola]

Hello,

Merci du ti message

Citation :

les dernières news de ton blog remontent à mai, j'dois me faire du souci ?

Absolument pas, le projet ne s'est jamais aussi bien porté qu'actuellement !
L'E3 (Eyengui Evironment Editor) vient de passer un nouveau cap cette semaine. Il est désormais capable de se brancher en live aux serveurs MySQL de jeu.

Ce qui veut dire que :
1. plusieurs personnes peuvent développer en meme temps sur le meme projet.
2. que nous allons maintenant pouvoir finaliser l'E3 pour commencer une vraie map de test

Nous organisons les projets suivant un mode opératoire de ce type :

Chaque projet est en fait composé de 3 bases spécifiques qui peuvent être copiées les unes sur les autres sans blocage.

1. Niveau développement, premier niveau, c'est ici qu'on developpe le jeu et qu'on le fait évoluer. Il n'est pas accessible aux joueurs.

2. Niveau Test. Une fois le développement terminé, on le passe en phase de test. La phase de test permet de régler le projet. En cas de problème grave, on peut écraser la base test par la base développement a tout instant et revenir ainsi a un niveau "propre". Cette base sera accessible pour des joueurs afin de faire des bétas ouvertes.

3. Niveau Production. la seule base accessible par le client de jeu standard.

Il va sans dire que le 1er projet qui sera concerné par notre outil sera WIMD mais nous avons une idée dans notre besace pour montrer les capacités MMO de notre projet.

a++
Nico

[Plombier]

Merci d'avoir pris le temps de me rassurer
Tu as avancé sur ton système de dialogue avec les PNJ ? J'ai trouvé ça très intéressant et j'aurais aimé avoir des infos sur l'évolution de ton système si tu y as apporté des modifications.

[leghola]

Hello,

Il est vrai que je donne pas trop de news car en fait j'estime qu'une news doit vraiment apporter un truc de nouveau et pas un simple "j'ai réussi a poser un décor youpi.." :-)
Je préfère ménager des effets de surprise avec de gros beaux trucs...

Nous passons énormément de temps au développement de l'E3, l'éditeur de monde, et alors que je recode plusieurs fonctions en essayant de faire un outil le plus simple et pratique possible au niveau de la 3d, Cédric avance dans la gestion des objets en live...

Niveau PNJ , non, nous n'avons pas plus avancé sur ce sujet

Voici un autre des concepts qui est en train d'etre implanté dans Eyengui :

Objets, Instances et Zones géographiques....

Chaque "chose" du monde créé sera créé tel le concept d'"Objet". PNJ, Arbres, Maison, Monstre, Nénuphar, etc... Sont des "Objets".

Chaque Objet possède des propriétés de 2 types principaux :

1. Propriétés Systèmes : Ce sont des propriétés indispensables au moteur et qui seront ajoutées a TOUT objet.
2. Propriétés Autres : A la liberté du créateur, il peut créer autant de propriété qu'il souhaite pour un objet, il pourra les classer en catégories et en faire ce qu'il veut. C'est propriétés seront celles utilisées de base dans le langage de script.

De plus chaque objet possède donc des "Savoirs", liste de textes qui peut être modifiée en cours de jeu (ajout, suppression, etc.). Les savoirs sont créés dans une table et donc plusieurs objets peuvent connaitre le meme savoir et des savoirs peuvent (et seront a coup sur) créés, modifiés ou supprimés en cours de partie.

Enfin, chaque objet possède des "évenements scriptés" via l'ESS (Eyengui Script System). Ces évenements ne sont pas figés et le créateur est libre de créer des évenements complètement farfelues suivant l'objet. exemple un évenement " arroser " associer a un objet "fleur", un évenement "faire pipi" sur un objet "arbre" etc...

Une fois ces objets créés, une arborescence de ces objets qui peuvent être classés par catégories, etc. est disponible. Via un simple DragAndDrop sur la carte 3d, le systeme créé une "copie" de l'objet créé. Cette copie conforme de l'objet est nommée "Instance" et chaque instance hérite des savoirs, évenements et propriétés de l'objet. Mais chaque instance peut être redéfinie personnellement a tout les niveaux.

Le monde en général est organisée en "Maps". Un damier de maps est disponible et permet donc de créer un monde gigantesque (la taille du damier est infinie)
Une instance est donc associée a une maps mais au dela de ca, une map est définie dans une "zone géographique" (La foret Turlututu composée de 8 maps)

C'est un des outils très spéciaux en cours de développement pour Eyengui : La génération automatique de zones géographiques.
En voici le principe :
Vous définissez une zone géo de X maps. Dès cette validation l'E3 demande si vous souhaiter construire une zone automatique.
Dès lors, un outil s'ouvre vous demandant la composition de cette zone et vous affiche la bibliothèque d'objets disponibles.
Vous choisissez les objets, leur pourcentage de répartition et après validation, le système créé une zone avec toutes les instances.

Exemple :
5 maps composent la Zone Géographique : Foret des oubliés.
Dès que l'outil de génération auto s'ouvre, vous ajouté a la composition :
20% de l'objet Arbre Chêne
15% de l'objet Arbre Peuplier
10% de l'objet Arbre Merisier
1% de l'objet Arbre Mort
3% de l'objet Animal Loup
2% de l'objet Animal Lapin

Après validation, le système va générer aléatoirement une zone complète a partir de ces demandes.

Il va ainsi être possible de créer des maps très rapidement.


a++
Nico

[Plombier]

Sympa tout ça ! Et concernant le langage de scripts, comment ça se passe ? Par exemple, je veux associer à une action, un mouvement précis aux joueurs. Combien de lignes de code ? En gros j'veux savoir si c'est bas niveau ou pas, si l'api permet en quelques lignes d'obtenir rapidement le résultat souhaité ?

Encore bravo et bonne continuation !

[leghola]

Hello,

Citation :

Par exemple, je veux associer à une action, un mouvement précis aux joueurs.

Hmm, désolé je ne comprends pas cette phrase. Pourquoi un langage de script devrait modifier le "controle" d'un joueur ?

Le langage de script sera du haut-niveau. En fait nous avons développé un systeme qui va permettre une grande souplesse dans le langage. Tout est "intellisense"

Je développerai un peu plus si tu peux me donner un peu plus de précision stp

Merci,
Nico

[Gardien]

Citation :

Publié par leghola

Hmm, désolé je ne comprends pas cette phrase. Pourquoi un langage de script devrait modifier le "controle" d'un joueur ?

ce que j'ai compris par sa question, c'est "avec un script pourra ton declancher un mouvement (action ?) precis ?". Par exemple, choisir l'animation pour pisser contre un arbre dans le script

[leghola]

Re,

Merci Gardien de cette précision.

Evidemment oui.
En fait, comme dis avant, chaque "chose" du jeu est un Objet. Les joueurs aussi seront des objets sur lesquels on pourra travailler.

Exemple de script pour un téléporteur par exemple

On créé un évenement qu'on va appeler "Activer", le "moi" represente l'objet qui possède l'évenement (ici le téléporteur) et le "activeur" représente le joueur qui déclenche l'action.
"Destination" représente la position(x,y) ou est envoyé le joueur via le téléporteur.

Code:

 
Action Activer :
 
CreerEffetGraphique(EffetTéléporteur, Moi.Position)
Activeur.Animer(BrasAuCiel)
Attendre(2 Secondes)
 
Activeur.Position (Destination)
Activeur.StopAnimation
SupprimerEffetGraphique(EffetTéléporteur, Moi.Position)

Et voila.

(ca réponds a la question )

a++
nico

[Plombier]

Désolé pour mon manque de précision ! Je n'ai plus de questions votre honneur

[Lazaris]

Hello !

@leghola :
Ayant fait un peu de programmation, je me posais la question suivante :

Comment se fait-il que dans le script que tu viens d'envoyer, le moi.position renvoie les coordonnées de moi, alors que quelques lignes plus bas, Activeur.Position() déplace Activeur ?

Ne risque-t-il pas d'y avoir des confusions entre .position et .position() ?

[Plombier]

L'un est un attribut de l'objet et l'autre une méthode. Ils n'ont que le nom en commun. Non ?

[leghola]

c'est une technologie .net

Une meme "fonction" permet de définir ou récupérer une valeur...

Dans le premier cas, je récupère la valeur que me procure la fonction position dans le 2eme cas je la redéfini. Mais ceci n'était qu'un exemple.

Pour que tout soit le plus accessible possible, il est tout a fait possible qu'il y ait deux "fonctions" :

.récupère_position
et
.défini_position

voila

[Gardien]

le langage de script sera en francais ? si oui, y aura t'il une version en anglais ?