1
\$\begingroup\$

Hope this is a proper question to ask here. If not, I'd appreciate somebody pointing me to other game developer communities. Since I am creating my game by myself it'd be nice to communicate with other developers.

Is it best to keep NPC stats in the database, or calculate them using code? I store the NPC's level in my database table. So from there I could use code to calculate it's Attack & Defense, and any secondary stats.

I can't think of any "Cons" to using just code. But a "Pro" would be that I can easily adjust the NPC's stats using different algorithms.

\$\endgroup\$
  • 2
    \$\begingroup\$ The answer probably varies for any given project based on a number of other design goals. If you won't need to change them while the game is running (at least in a way you can't calculate based on level) my personal inclination is to just calculate them until you have a clear need to put them in the database. But this opinion assumes your code roughly is the game, and not that you're building an engine that could run a number of different games depending on what's in the database. \$\endgroup\$ – abathur May 28 '15 at 22:52
  • 1
    \$\begingroup\$ If your question is "What would be a pro to store it in db?"; I see 1) speed: 1 fetch and 0 calculation instead 1 fetch and X calculations 2) debug ease: "where is this value coming from? Ah yes, there in the db!" 3) tweak (and "cheat"), as you mentioned. \$\endgroup\$ – Alexandre Vaillancourt May 29 '15 at 2:28
  • \$\begingroup\$ Thank you for your inputs! You both make very excellent points. \$\endgroup\$ – Draven May 29 '15 at 3:08
  • 1
    \$\begingroup\$ I would base my decision based on whether the NPC stats feature any randomly selected skills. For example, like DnD 3.5 rules. A 3rd-level Fighter will have a bunch of feats. My NPC generation might pick these at random. So re-creating the character in code every time would result in a slightly different character. To add permanence, I would instead store everything in a DB. If this isn't the case then I would steer clear of the DB as it adds complexity and depth to your stack that you don't need. Unless you know you will need it for something else, it's not worth the resources. \$\endgroup\$ – NeomerArcana May 29 '15 at 10:38
1
\$\begingroup\$

I would say both code database. Perhaps also a software component, in the server-side, to leverage access to databases and have a kind of poor cache (the actual intention is not to do cache, but maintain objects as being alive).

With code you will define basic algorithms and, perhaps, rebalance the enemies in the future. Perhaps the code could involve a script loaded from database which could be maintained and modified as required (note for purists: using code evaluation under this requirements would not be unsafe since only the application administrators could configure them. Even enterprise software like OpenERP can have code chunks for certain record types and nobody complains about that).

With database you could store the deltas for each stat (e.g. in a Pokemon-like game, a delta would be a stat modified temporarily by an attack or an item). In a Pokemon-like game, also the permanent stats are saved into database (since there are objects that alter the permanent stats).

So your needs will depend on the type of stats for your NPCs:

  • Base stats, able to be permanently and temporarily modifiable: Use code for when the NPC raises a new level (if it is the case) or for initial calculations. Use database for actual permanent values, and choose either between database or just memory for temporary modifications.
  • Base stats, able to be temporarily modifiable: Use code for initial calculations. Choose either between database or just memory for temporary modifications.
  • Base stats, not modifiable anyhow: Use just code for the initial calculations.

Architectural considerations: Your HTTP server should be able to maintain live objects globally between different HTTP sessions. Cases like Tornado and Twisted (for Python) or almost any java web framework can help you. For PHP you will need a database (since you cannot globally have in-memory live objects).

Notes: Maintaining live objects It is also not the case with architecture based on worker processes (synchronous-based servers like Python/gunicorn fall in this category) since each worker process would maintain a copy of the live objects and that would be troublesome for similar reasons than using PHP.

\$\endgroup\$
0
\$\begingroup\$

I would say databases would be preferable.

Let's say you build an 'arena' page of your site. The arena page randomly picks a monster for you to fight that's within 5% of the challenger's level. This would be more-easily achieved with a quick SQL statement.

Or, let's say you wanted a bestiary page so your players could search for a monster that drops X or Y. This would be difficult to achieve in code-based NPCs.

That said, if you're thinking about creating a database only for storing NPCs and not character credentials etc. you have to decide if the long-term maintenance, performance overhead etc. of it is worth the implementation.

\$\endgroup\$
0
\$\begingroup\$

If you are 100% sure that the NPC's level will always be enough to specify their stats, then level in db/calculations on client is a good option. Less hitting the db means your game scales better with the number of players.

However, it locks your design into this box. There are ways to patch on differences not related to level at a later date, but this could cause problems as the rest of your game might not be coded or designed with this in mind.

So this decision depends on how likely it is that the current design will be the final design.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.