1
\$\begingroup\$

Is it a bad idea to use hard coded values for things like items (static data) that would change infrequently in an online game? I'm designing an online game in node js, and I'm trying to decide if it would be better to store the data in a database, or hardcoded in a javascript hash (and maybe cache some of the data in a db for filtering). Points I've thought up:

Since javascript is a scripting language, updating it wouldn't be a big deal, it would mean restarting the server, but it would seem most online games go through some sort of restart when introducing new things anyways.

Items in my game are really hard to define in data, as they can have wildly different functions, if its a javascript object, I can define a 'use' function for all of them and don't need to worry about creating a complex item definitions in the database.

If I used a database only, I would have to come up with some sort of way to define every possible item ever, and I don't think its likely I will imagine all of them.

I could use a database for things like name, and description, but still have a hash of functions somewhere.

Maybe having all these items hard coded could increase memory foot print of the web application as they would all always be loaded into memory?

I'm afraid I'm missing something important though? Is there a better answer? Or just preference? Is there a clear right way to do this?

\$\endgroup\$
  • \$\begingroup\$ Maybe I'm reading this wrong, but it sounds like you could send JSON data. Have Item types, for example a weapon type has attributes like damage. Make the client send the type of item they want? - I think using a database would be best for this, have you heard of firebase? \$\endgroup\$ – Everless Drop 41 Aug 11 '15 at 1:15
  • 1
    \$\begingroup\$ I don't know why this is down-voted. This seems like an interesting question to me. \$\endgroup\$ – ashes999 Aug 11 '15 at 1:39
  • \$\begingroup\$ @ashes999 It's quite opinion based IMHO. \$\endgroup\$ – Vaillancourt Aug 11 '15 at 12:48
3
\$\begingroup\$

Rather than hard-coding your data in Javascript, why not use JSON. It's always a good idea to separate your data from your program, and splitting out item definitions into JSON files would be very clean I think. Node even let's you use "require" with JSON files, how handy: How to parse JSON with node

Databases are a great technology to learn if you haven't already, but you should be careful to add that sort of complexity to your game before you really need it. Unless you have tens of thousands of item definitions, I would not worry about the memory or bandwidth impact you would have storing this data in a file that's loaded by clients all at once.

\$\endgroup\$
2
\$\begingroup\$

Since javascript is a scripting language, updating it wouldn't be a big deal, it would mean restarting the server, but it would seem most online games go through some sort of restart when introducing new things anyways.

You really don't want this.

Yes, some items will need reboots, because they'll need new accompanying game logic. Minor updates, GM-driven quests, marketing-driven quests and bonus items (or pricing changes), etc. should absolutely not require a reboot.

Honestly, even code changes shouldn't require a reboot in this day and age. Incremental rollouts are quite possible, even in an MMO.

Items in my game are really hard to define in data, as they can have wildly different functions, if its a javascript object, I can define a 'use' function for all of them and don't need to worry about creating a complex item definitions in the database.

This is not a good reason to hard-code the data. Your need to hard-code the behavior of an item is irrelevant to your need to associate a name, or a cost, or a weight, or an icon, or anything else with the item. Hard-code what you need to; nothing else.

Even with item behavior you probably want to parameterize all that. You shouldn't need 10 different use() functions for similar but different features. A single heal() function could be used across most if not all healing items, for instance, allowing the item to define in data how much healing is applied.

Then you can allow items to have multiple functions. Instead of a complex heal_100hp_and_cast_lvl3_fireball() you can instead have heal(hp) and cast(spell, level) functions and then allow an item to require both of them. Even the heal(hp) function can be further parameterized to allow a single function to handle healing by explicit amount, by percentage of max HP, etc.

Put your mind to it and you'll see that you only need a relatively small set of individual functions to implement a very wide variety of both simple and complex items. That makes your code much simpler, decouples your behavior from your items, and even allows totally new complex items to be created and released without ever touching a single line of code.

If I used a database only, I would have to come up with some sort of way to define every possible item ever, and I don't think its likely I will imagine all of them.

You have to do that even without the database. Whether they're in your code or in your data, you have to keep around all items you release forever.

Players don't tend to like it when items they "own" just up and disappear because you decided to trim a few hundred thousand lines of code out of a bloated codebase.

Once an item is released, it exists forever. Do you want your code to keep growing forever until it's utterly unmaintainable or would you rather have a big database designed for handling terabytes of data hold on to some legacy data entries?

I could use a database for things like name, and description, but still have a hash of functions somewhere.

Yes. Do that. Combine that with database-supplied parameters for the functions.

Maybe having all these items hard coded could increase memory foot print of the web application as they would all always be loaded into memory?

Well, yes, but that's not a good reason to avoid it. There are good reasons (see above); that's just not one of them. :)

\$\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.