Browser-Based Game Design: Keeping track of NPC stats (Attack, Defense, Health, etc)

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.