I need help deciding what method would be best suited for my open world game. I have two thoughts about how to read variable data for the Monsters. Basic question is would it be a better practice to read variables from the monsters object using the built in variable system or should I create a database via MySQL? What would be the Benifind and what would be the risks of each?
So far I am leaning more and more to the MySQL database for several factors. First and foremost is the ability to patch the game at a later time should the need arise. Rather then having to manipulate every creature in the game one by one you can use a database that is on the server (Read Only Access) and patch it by modifying the data table on the server. The second key thing to note is that MySQL being on a sever rather then in the game would free up memory and the game will be a smaller file without all the data in the game itself. Lastly with MySQL I could hook it up to a website where you can use the search feature and display stats allowing for a search feature and staying organized.
So the main question here is thier any huge advantage to using the UE4 system to store variables? Just wanna make sure I am not missing something as with the scale of the game it’s a ton of data if I screwed up.
UE4 vs MySQL storing variables
SQL is the way to go, like you say. The MySQL C++ library is great.
Pardon me if you're already in the know, but the first thing one needs to learn are the first three normal forms – https://en.wikipedia.org/wiki/Database_normalization
Thank you for The advice. I have dealt with many projects that used SQL for both website and video games and was more wondering if I missed a feature about UE4 that I was unaware of. i am familiar with data entry as I had to take several classes on it for my CIS degree. I plan on creating a similar structure to the ones World of Warcraft private servers used to use as the game will be open world and it would be beneficial should any updates and DLC is later needed (or if it goes really well have the base codes for a new open world game) and before it’s asked yes I know that’s a ton of data that will need entered and yes I will be hiring a team once I get all the correct legal forms for my company.
Well, if you have Microsoft office, you can use VBScript to programmatically access data within Word and Excel files. So really, the data entry is guaranteed to be correct, robust, and most importantly, automatic.
Not sure if OpenOffice is programmable like that, but wouldn’t that be so cool? LOL
This thread is surreal. As far as I can remember video gaming and RDBMS were two distinct worlds but who knows how the things roll those days.
SQL was a major center of cost in nearly all companies I worked (in one, it effectively shut off the company). I would also point out that insisting on calling it MySql instead of the proper MariaDB tells a lot. As far as I am concerned the only RDBMS making sense is Sqlite.
Basically none of your assumptions make any sense to me but just in case I'm missing the obvious, how many thousands of monster kinds you plan to have? How many updates, mission packs per week?
Runiker said:
So the main question here is thier any huge advantage to using the UE4 system to store variables? Just wanna make sure I am not missing something as with the scale of the game it’s a ton of data if I screwed up.
Please elaborate. What is a ‘ton’ of data?
I would say the main advantage of doing things by the book would to cater to the experience Epic accumulated over decades of experience by serving its customers. Doing things by the book might bring you vastly better documentation and to be completely honest I would expect a huge performance loss in pulling in RDBMS to … wait… are you really talking about using a database for modifying actor stats at runtime?
Rather then having to manipulate every creature in the game one by one you can use a database that is on the server (Read Only Access) and patch it by modifying the data table on the server.
I will take a stretch and state I have observed this in (more than) one company I worked for. They were reasoning in increments of 5 seconds.
Previously "Krohm"