PNJ, ou comment faire évoluer des évenements non liées a des joueurs?

[gtsoul]

tu te rappelles notre discussion sur les processus ?
tu peux faire un cron qui pointe vers un script en cshell, (un script shell qui se rapproche beaucoup du c et qui peut appeler quelques programmes c de ton cru, ou même un script php)

certes c'est pas optimal car ce genre de processus devrait être intégré à ton moteur, mais c'est déjà pas mal, et cela se met rapidement en place. Un cron ne consomme pas tellement de ressources.

Autre solution, tu crées un programme c autonome avec moults fork qui vont chacun travailler sur la bdd (par contre tu as interêt à vérifier ton pool de connection pour éviter que celui-ci ne sature le nombre d'accès).
Pourquoi en c et pas php ? j'aime bien ce language, il est compilé donc plus rapide et surtout tu n'as pas besoin d'envoyer de page à un client donc tu n'utilises pas tout un pan de la technologie php; et tu peux logger le résultat de tes actions.

[NicoMSEvent]

tu te rappelles notre discussion sur les processus ?
tu peux faire un cron qui pointe vers un script en cshell, (un script shell qui se rapproche beaucoup du c et qui peut appeler quelques programmes c de ton cru, ou même un script php)
certes c'est pas optimal car ce genre de processus devrait être intégré à ton moteur, mais c'est déjà pas mal, et cela se met rapidement en place. Un cron ne consomme pas tellement de ressources.

Ce que je pense etre mauvais : le cron ne saurais pas lancer assez de mise a jours à la seconde (c'est du temps réel)
De pus, que ce passerait-il si il tenterait de relancer une procédure qui ne serait pas encore terminée?

Autre solution, tu crées un programme c autonome avec moults fork qui vont chacun travailler sur la bdd (par contre tu as interêt à vérifier ton pool de connection pour éviter que celui-ci ne sature le nombre d'accès).

Ce que je pense etre bon : le programme sera une boucle infinie en background (histoire qu'il ne bloque pas tout), qui mettrai a jour tous les éléments non-joueur du serveur en fonction de leur environnment. Donc, ce serait un programme indépendant

MAIS (parce qu'il y a un mais), pas de moults fork, qui ne feraient qu'encombrer la mémoire et du temps processeur. Je ferais un système ou chacun son tour analyse la situation courante, et prend une seule décision.
(éventuellement, je mettrais mon serveur a jour -> dual core)

Pourquoi en c et pas php ? j'aime bien ce language, il est compilé donc plus rapide et surtout tu n'as pas besoin d'envoyer de page à un client donc tu n'utilises pas tout un pan de la technologie php; et tu peux logger le résultat de tes actions.

Ce n'est pas PHP qui envoie ta page aux client, mais apache ^^
Par contre, c'est vrai que je n'aurai pas besoin des sessions, cookies, explode et autres fonctions spécifiquement liées au web.
Je maitrise aussi le C, je sens que c'est ce que je vais adopter comme langage (a moins le C++...)

ça sera (presque) une premiere pour moi, un gros programme en C sous linux! ^^

[gtsoul]

si tu veux j'ai des cours (plus des tps) en c qui devraient t'intéresser.
C'est en rapport avec ce genre de programmation (synchronisation, multiprocessus et communication), tu en as bien pour 2-3 semaines à l'assimiler si tu as de bonnes bases en c.

Tu peux adopter l'architecture suivante :
un programme mère coordonne tout un ensemble de fils qui accomplissent chacun une action donnée très précise et très succinte (un pour gérer le déplacement des monstres, un pour gérer le déplacement des pnj, un autre pour les attaques des monstres).
Cela simplifiera le programme en lui-même et stabilisera ton jeu (l'un d'entre eux peut planter, il ne genera pas les autres et sera tué et relancé par sa mère)

[NicoMSEvent]

Merci de ta poposition... mais j'ai donné cours de rattrapage de C système (sous linux avec tout ce qu'on veut comme threads etc), je connais assez bien la matière, n'empeche que je ne me sent pas a l'aise avec la pratique.
Je vais replonger dans ma théorie, et essayer d'y joindre la pratique ^^

Mais pour le moment, ce n'est pas encore a l'ordre du jour. J'ai encore mes modèles 3D a animer, et surtout la gestion (linéraire) des monstres (j'organiserai le découpage en threads plus tard, quand le besoin s'en fera sentir)