Moteur de jeu ?

[Myrina]

Et notamment comment intégrer ça dans Symfony ou un autre framework.

Je pense que tu prends le problème à l'envers: d'abord le framework: le comprendre, le maitriser et ensuite le compléter/l'améliorer avec de nouvelles fonctionnalités

[srm]

Et bien c'est à voir en fait, par exemple au sujet de la procrastination, ce que j'ai envie de le faire, je le fais sans le remettre au lendemain et je préfère ne pas faire quelque chose plutôt qu'il ne soit pas fait à ma convenance (en projet personnel) c'est un choix, qui souvent m'amène à rien faire, mais si j'en suis conscient et que je l'accepte je n'y vois pas de soucis

Après dans tout projet au contraire j'attaque la partie la plus pointue la plus problématique, si j'arrive à la résoudre et la faire je sais que le projet peut sortir (bon en général quand j'ai dépassé le défis technique, le projet ne m'intéresse plus trop lol).

La partie simple je sais que je peux la faire facilement, donc je réfléchis déjà à la plus pointue voir ce que je peux faire

---

Non mais c'est bon je gère au niveau Framework: CakePHP, Zend Framework, Symfony 2 et même mon propre framework.

Ce qui pour le moment me pose soucis en fait c'est déjà la couche modèle.
De loin à chaud comme ça, je ne vois pas comment je peux faire un truc qui ne soit pas usine à gaz au niveau du modèle.

Sauf peut-être si mon moteur créer carrément le code du modèle pour qu'il soit aussi simple/clean (enfin dans l'idée) que si il était fait à la main spécialement pour le besoin demandé.

---

Après sur la même idée, soit on a tendance à avoir une usine à gaz au niveau de la base de données, soit le moteur créer carrément les tables selon les besoins, ce qui cependant peut-être compliqué à gérer si on ne veut pas lui faire perdre les données qu'il a déjà inséré.

Ou alors encore utiliser une base du type MongoDb qui pourrait tirer son épingle du jeu pour le besoin.

[NicoMSEvent]

Donc, si je te suis bien, la majorité de l'intelligence du moteur devrait se situer dans le parametrage de l'installation, afin d'éviter les lourdeurs/portions de code non utilisé (bien qu'il me semble que dans l'orienté objet, c'est faisable au vol), et en conclusion "brider" le jeu en fonction du genre qu'on souhaite lui donner.

J'avoue que c'est un gros raccourci que je fais là, mais il me semble que l'idée sous-jacente y est

[srm]

Hum ? Ca n'est pas vraiment ce que j'ai dit.

Au lieu d'avoir :

<?php

class GenericModel {

    public function get($model, $property)

    {



        $em = $this->get('doctrine.orm.entity_manager');

        return $em->createQuery('SELECT s.value FROM MyGameropertyList s WHERE s.model = :model AND s.property = :property')

            ->setParameter('model', $model)

            ->setParameter('name', $property)

            ->getResult();

    }

}





class PlayerModel extends GenericModel {

    public function __get($name)

    {

        return $this->get('player', $name);

    }

}

Ce qui au passage n'est pas un modèle Doctrine et je voudrais un modèle Doctrine.

Avoir directement le code :

<?php



namespace Application\MonJeu\Entity;



/**

 * @orm:Entity

 */

class PlayerModel {

    /**

      * @orm:Column(type="string")

      */

    protected $name;

    /**

      * @orm:OneToOne(targetEntity="Town")

      *

      */

    protected $town;

    /**

     * @orm:Column(type="integer")

     */

    protected $money;







    public function getName()

    {

        return $this->name;

    }



    public function getTown()

    {

        return $this->town;

    }



    public function getMoney()

    {

        return $this->money;

    }

}

[pascal]

Ce moteur de jeu peut exister pour plusieurs types de jeux :
- une application générique pour les choses communes (inscription, messagerie & co ...)
- un module pour chaque type de jeu

A+

Pascal

[Shao]

Attention à ne pas oublier une contrainte essentielle : le moteur doit tourner sur du PHP/MySQL (ou alors il faut que le SGBD soit assez simple à installer le problème étant que la plupart des hébergeurs fournissent un MySQL et un FTP donc si c'est un autre SGBD, où le mettre afin de le sécuriser ?) afin que l'administrateur ne soit pas contraint aux niveaux des hébergeurs.
Ça parait évident comme contrainte mais on sait jamais.

Pour la BDD, ta seconde solution oxman me semble plus judicieuse (créer des relations selon les besoins). Sans rentrer dans les détails, j'imagine bien une table Module mappé sur un répertoire contenant du code. Dans ce répertoire on retrouve des scripts sql de création/activation/désactivation/suppression du module et quand le module est activé on peut exécuter le code à l'intérieur. Avec les frameworks actuels (je pense notamment à Zend), ce système ne doit pas être super compliqué à mettre en place.

[srm]

Pour le moment j'ai pas comme objectif de me contraindre à une technologie ou une autre. Puisque le but principal et de faire un système clé en main, la personne n'aura rien à installer tout sera hébergeur sur des serveurs dont j'aurais la gestion.

La possibilité d'exporter l'application pour l'installer soit même sur un serveur ne sera pas utilisée par grand monde je pense. Et ceux qui le feront devront sans doute avoir un dédié. Puisque de toute façon je pars pour le moment sur PHP/PostgreSql.

Je ne suis pas sûr que je me sois bien fait comprendre sur la deuxième solution Shao.

Pour la deuxième solution en effet le moteur de jeu doit à un moment faire quelque chose de ce genre :

<?php



$f = fopen('Entity/Player.php', 'w+');



$em = $this->get('doctrine.orm.entity_manager');

$params = $em->createQuery('SELECT s.property, s.value, s.type FROM MyGameropertyList s WHERE s.model = :model')

        ->setParameter('model', $model)

        ->getResult();



foreach($params as $param) {

    fputs($f, "/**\n");

    fputs($f, " *\n");

    fputs($f, " * @orm:Column(type=\"" . $param['type'] . "\")\n");

    fputs($f, " */\n");

    fputs($f, "protected $" . $param['property'] . ";\n");

    fputs($f, "\n");

    fputs($f, "public function get" . ucfirst($param['property']) . "()\n");

    fputs($f, "{\n");

    fputs($f, "     return $this->" . $param['property'] . "\n");

    fputs($f, "}\n");

}

[srm]

Ceci dit du coup avec cette approche, je ne vois pas de difficulté à créer un moteur de jeu, ça serai juste long et fastidieux de faire tous les modules avec plein de configuration.

Ca m'intéresse moins du coup.

[Viciousity]

Ceci dit du coup avec cette approche, je ne vois pas de difficulté à créer un moteur de jeu, ça serai juste long et fastidieux de faire tous les modules avec plein de configuration.

Ca m'intéresse moins du coup.

Mouais en partant comme sa tout est simple (facebook c'est toujours que des if, des elses, des boucles) et sa ne sert a rien de coder (a)

[srm]

En effet Facebook est simple, ce qui est juste compliqué c'est de gérer la charge