[Résolu] Comment stockez-vous vos quantités de ressources ?

[Arnadus]

Je sais, j'ai bien compris.
Mais ta première solution n'est pas bonne au niveau relationnel.
C'est comme si tu avais envie de trop externaliser le concept de ressources.
Dans ta table "resource_type_thing" par exemple:

thing_id : l'id de la chose à laquelle on attache cette quantité (convoi 42, territoire 66) ;

Ca, par exemple, n'est pas possible avec un SGBD classique. Tu ne pourras pas définir de foreign-key à la foi pour convoi, territoire, unités etc...

Donc bon, désolé lol mais pour moi aucune des solutions que tu présentes n'est envisageables. Les 2 dernières ne sont pas assez recherchées et la première est plus une prise de tête ( non non supportées par la majorité des SGBD) qu'autre chose.

[srm]

Moi je ferais un système simple et flexible, mais pas comme tu le dis.
Je ferais comme le système simple et rigide sauf qu'au lieu de stocker comme ça :
consumption_resource_type_1_quantity, consumption_resource_type_2_quantity, harvesting_resource_type_1_quantity.
je ferais une table de jointure pour chaque usage.
Exemple pour :
- Pour chaque parcelle, un type de ressource produit, sa quantité maximale, sa quantité actuelle et son facteur de régénération (exemple : la parcelle P produit une ressource R, il y a 100/120 unités dans la parcelle, avec une régénération de 2 unités par heure) ;
parcelle_id, resource_id, resource_max, resource_quantity, resource_regen

Pour chaque type de bête, sa capacité de récolte d'une bête pour chaque type de ressource (exemple : la fourmi peut ramasser 20 unités d'herbe par heure et 12 unités de feuille, le scarabée 6 unités de pierre par heure) ;
bete_id, resource_id, resource_quantity

Etc...

[Sephi-Chan]

Effectivement, après réflexion mon abstraction pour ce système ne semble pas être la bonne. La duplication de ces colonnes me dérangeait et j'avoue ne pas avoir pensé à la solution simple de remplacer chaque groupe par une seule foreign key vers une table qui décrirait un quantité de ressources ; disons resources_quantity, contenant une colonne par type de ressource.

Je pense donc opter pour ça ! Merci !

Du coup, mon autre erreur a été d'inclure le besoin de décrire la production d'une parcelle par ce même mécanisme. C'est indépendant.

[Arnadus]

Effectivement, après réflexion mon abstraction pour ce système ne semble pas être la bonne. La duplication de ces colonnes me dérangeait et j'avoue ne pas avoir pensé à la solution simple de remplacer chaque groupe par une seule foreign key vers une table qui décrirait un quantité de ressources ; disons resources_quantity, contenant une colonne par type de ressource.

Bonne décision!
En plus avec cette méthode, tu pourras facilement gérer ton formulaires (je pense notamment à toute la partie administration) si tu utilises le composant "Form" de symfony par exemple. Le matching sera super simple à faire.

[Sephi-Chan]

L'API côté objet étant en place, l'implémentation sous-jacente ne va rien changer au code existant

Côté technique, c'est du Ruby. L'application est découpée en plusieurs petits composants (qui prennent la forme de daemons) qui communiquent via RabbitMQ, avec des composants annexes comme une application Ruby on Rails pour la partie Web et un serveur WebSocket pour le push (qui sera probablement remplacée par un serveur SSE à terme).


Je renouvelle mes remerciements : vous m'avez ouvert les yeux sur quelque chose qui était devant mon nez !

[srm]

Tu peux me tutoyer tu sais

[php_addict]

J'arrive un peu tard mais:

Surtout pas de sérialisation pour de données aussi cruciales du jeu, car:

- pas facilement maintenable, modifiable
- compliqué à débuger car pas très human readable
- et surtout car tu peut faire autrement et bien plus propre

A mon sens il faut réserver la sérialisation de donnée uniquement quand il est bien trop lourd de faire autrement, sinon ne pas l'utiliser...

[Sephi-Chan]

Tu peux me tutoyer tu sais

Je pensais plus à Arnadus en l'occurrence, car j'ai pas compris ta solution, mais l'important c'est de participer. :p

J'arrive un peu tard mais:

Surtout pas de sérialisation pour de données aussi cruciales du jeu, car:

- pas facilement maintenable, modifiable
- compliqué à débuger car pas très human readable
- et surtout car tu peut faire autrement et bien plus propre

A mon sens il faut réserver la sérialisation de donnée uniquement quand il est bien trop lourd de faire autrement, sinon ne pas l'utiliser...

Comme je le répète, les mécanismes que j'évoque sont intégrés à la base de données, c'est transparent à l'utilisation et on peut même requêter dessus (cf. hstore dans PostgreSQL) : ce n'est pas sale et la lecture est très aisée.

Si je n'opte pas pour ça, c'est que l'utilisation relationnelle pose des contraintes que j'apprécie, car elles encadrent bien l'application. Mais je ne crois pas que ces données auraient été difficiles à maintenir.