I am working on the way I handle information using MySQL data tables for the action RPG project I am working on. I am wanting to have a lot of information accessible by all the servers being hosted at once, and I want players to be able to easily switch between the different servers possibly even during game play.
I am currently trying to figure out the best way to handle objects. There are two programmers that are working on the project and the two of us have come up with completely different ideas as to how we would handle them.
One of the ideas is to have all object/skill/quest pretty much any node that can have different information such as stats rewards etc saved to them, put an identifier for all of these and their stats into the database and when the game first loads create an object with those identifiers and statistics.
The other option is to have a hard coded list of all the objects that need to be saved in the game in a format such as
obj_ide["[ide]"]=new/obj
and then call on that specific identifier to create a new object of that type in the players inventory upon loading. Either way this part will work about the same. It is mainly where we should store the primary list of objects either in the game itself or in a database. I am a little curious as to what the best way to try to implement this would be. Do you guys have any ideas that are totally off base from where we currently are? Do you think I'm about on the right track?
ID:1303847
 Jun 26 2013, 1:32 pm (Edited on Jun 26 2013, 1:59 pm)
|
|
I was thinking that it would be much faster to have them hard programmed. The other developer had some interesting arguments for his systems which I found very cool. Such as being able to make new permanent items just by adding items manually or through systems created in game to the database which is interesting. They both seem to have their advantages and disadvantages, it comes down to if the additional load time in the beginning is worth it or not. I feel like I would rather worth linear with the game, and have a great story developed slowly. The kind of advantages that come with the second system seem like they support quickly building quests and such like you see in more modern games.
| |
Yep and that's the beauty of having a database instead of hardcoding everything, this also eliminates reboots for players and makes everything more dynamic, one question you have to ask yourself is, If I create X Quest on server2 when will it be picked up on server1 and server3, and how often should it check for new items in the DB.
| |
I also want to add on to this, that at runtime you could potentially check all tables in the DB and cache all new items, the first run of a server would cache everything in the DB, then any other run would only pick up new items and cache those.
This will help you if the DB server ever went offline, everyone could keep playing like nothing ever happened. | |
Assuming the logic of quests, skills etc is fairly generic or can be templated in some way, then yeah, you can definitely load up all that information from the database. It's usually not too difficult with good design to make up a good set of re-usable bits of logic you can bolt together.
Certainly, NPC dialogue (and how people progress through that) can be loaded off your database and then easily changed up, making for say ... events where everyone talks like a pirate, etc. As ATHK rightly notes, if you take that route, load it up on start-up and cache it. Restarts are preferably a rare thing, so slower startup is no bad thing in itself. Fault tolerance to losing the MySQL connection, and a seamless user experience, are more important. | |
example > server1 searches all of the Obj table for column (allowed_on_server) if allowed_on_server equals the server's number (1 in this case) retrieve the information of the objects and create them.
If that makes sense?
Hard coding them will allow for faster startup time and less bandwidth.