Comment organiser au mieux la composante règles d'un système Django?

voix
4

Je suis la conception (et, finalement, écrire) un système de Django qui se compose de deux éléments principaux:

  1. Un gestionnaire de jeu: c'est essentiellement une pièce de saisie de données. De confiance des utilisateurs (non publics) entreront informations sur un système de jeu, comme les options qu'un joueur peut avoir. L'interface de c'est uniquement la console d'administration de Django, et il ne rien « faire », sauf tenir les informations.
  2. Un gestionnaire de caractère: c'est le consommateur des données ci-dessus. Les utilisateurs publics vont créer des personnages dans les systèmes de rôle définis ci-dessus, tirant des options saisies par les utilisateurs de confiance. Ceci est une application distincte dans le projet du point de vue de Django.

Il y a un morceau que je ne sais pas où mettre, cependant, et ce sont les « règles » qui sont associés à chaque jeu. Essentiellement, pour chaque jeu mis dans la première application, il y a des ensembles de conditions, des limites et d'autres logiques d'affaires spécifiques à ce jeu. (Il y a aussi la logique de la même structuré qui sera commun à tous les jeux.) La logique va être codé en Python, plutôt que saisies par l'utilisateur.

Cette logique est utilisée dans le processus de validation d' un caractère particulier, mais est associé à un jeu particulier et devra être permutées dynamiquement. Est - ce une application séparée, ou doit - elle être liée à la validation des formes du gestionnaire de caractères? Ou peut - il être à la fois?

Ceci est la première application Django, je l'ai construit à partir de zéro (plutôt que de mâcher sur le code de quelqu'un d'autre), et je suis nouvelle à la philosophie Python pour démarrer, donc je suis toutes les oreilles à ce sujet.

Merci d'avance.

Créé 17/08/2010 à 16:54
source utilisateur
Dans d'autres langues...                            


2 réponses

voix
1

les « règles » qui sont associés à chaque jeu.

pour chaque jeu mis dans la première application, il y a des ensembles de conditions, des limites et d'autres logiques d'affaires spécifiques à ce jeu.

Cela fait partie de l'application de jeu, puis.

Il y a aussi la logique de la même structurée qui sera commune à tous les jeux.

Cela fait partie de l'application de jeu, puis.

Cette logique est utilisée dans le processus de validation d'un caractère particulier, mais est associé à un jeu en particulier.

Correct. Cela fait partie de l'application de jeu, puis. Les caractères sont associés à un ou plusieurs jeux.

devrait-il être lié à la validation des formes du gestionnaire de caractères?

Les caractères formulaires peuvent avoir des règles de nettoyage des données qui dépendent d'un jeu.

Créé 17/08/2010 à 18:00
source utilisateur

voix
1

Je voudrais créer sous - répertoire de règles nommées dans l'application avec la logique de jeu et il créer module nommé après chaque jeu, que vous voulez servir. Ensuite , créez une interface commune pour les modules, qui seront utilisés par vos jeux et l' importation correcte module de règles par nom (si votre jeu est appelé Adom, alors simplement à l' __import__('rules.adom')intérieur du principal moteur de jeu et appeler des méthodes spécifiques de jeu.

Si vos jeux ne puis pas créer propres modèles et points de vue , il semble y avoir aucune raison de créer l' application spécifique pour chacun d'eux. Ceci est une question délicate, parce que le code utilisé est basé sur les données stockées dans la base de données. Est-ce que pensez - vous pas sur le stockage des scripts de jeu supplémentaires dans la base de données puis execles? Cela semble plus naturel: un jeu est un ensemble de données et des scripts supplémentaires associés à ce jeu.

Créé 17/08/2010 à 17:27
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more