Calculateur de coût point buy D&D

Construire un personnage de cinquième édition avec la méthode d'achat par points du Manuel des Joueurs signifie que chaque score de caractéristique de huit à quinze a un coût fixe, et que les six coûts doivent tenir dans le budget de votre campagne—en général vingt-sept points. Ce calculateur de coût point buy D&D accepte Force, Dextérité, Constitution, Intelligence, Sagesse et Charisme, consulte chaque score dans la table officielle 5e, renvoie le coût par caractéristique et le total, et compare optionnellement ce total à un budget pour que vous voyiez les points restants ou le dépassement.

Comment fonctionne la table de coût point buy de cinquième édition

Le paquet classique de la répartition standard—quinze, quatorze, treize, douze, dix et huit—somme exactement vingt-sept points sous cette table, c'est pourquoi beaucoup de tables utilisent vingt-sept comme budget par défaut. Si vous envoyez un score de seize ou de sept, la requête échoue avec invalid_input en nommant le champ, conformément à la règle selon laquelle le point buy ne vend que de huit à quinze.

Contrat d'entrée, forme de la réponse et comparaison de budget

Associez la réponse à votre propre interface pour assigner les scores aux rôles ou appliquer les bonus raciaux après l'achat ; ce point de terminaison ne valorise que les six scores d'achat et n'applique ni traits d'espèce, ni dons, ni prérequis de multiclasse. Envoyez en POST un corps JSON avec six scores entiers obligatoires : strength, dexterity, constitution, intelligence, wisdom et charisma. Chacun doit être un nombre entier de huit à quinze ; les alias courts str, dex, con, int, wis et cha sont acceptés. Un entier optionnel budget (défaut vingt-sept, plage de zéro à cinquante-quatre) est la réserve de points de campagne utilisée uniquement pour la comparaison. Champs manquants, non entiers et scores hors de huit à quinze échouent avec invalid_input et ne sont pas facturés. En cas de succès le corps renvoie les six scores, un objet costs avec le coût en points de chaque caractéristique, total_cost comme leur somme, le budget effectif, remaining comme budget moins total_cost, within_budget comme booléen vrai lorsque remaining est non négatif, et un libellé cost_table identifiant la carte PHB 5e. Exemple : quinze, quatorze, treize, douze, dix et huit donnent les coûts neuf, sept, cinq, quatre, deux et zéro pour un total_cost de vingt-sept, remaining zéro et within_budget vrai sous le budget par défaut. Si vous fixez budget à vingt en gardant les mêmes scores, remaining devient moins sept et within_budget est faux—utile pour des règles maison sans changer la table de coûts.

Où une API de coût point buy justifie son existence

Les constructeurs de personnages et les applications compagnons de VTT ont besoin d'un petit oracle qui revalorise un brouillon dès qu'un joueur passe Constitution de treize à quatorze et s'attend à ce que la réserve restante baisse de deux, pas d'un. Les aides de session zéro et les feuilles d'équilibre de groupe comparent six PJ au même budget pour que personne ne glisse un seize par mauvaise lecture de la table. Une validation en échec ne consomme pas le solde. Les bots Discord et les enveloppes de commandes peuvent envoyer les scores en POST depuis un message et répondre avec total_cost et remaining sans embarquer la logique de la table dans chaque bot. Comme l'implémentation est pure parse de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle ni réseau sortant. Gardez les requêtes légères, figez total_cost et l'objet costs dans les tests, et vous obtenez des totaux point buy reproductibles pour constructeurs, blogs et workers de bord sans déployer un moteur de règles complet.