ID:53044
 
Keywords: design
It is very much a common requirement for RPG games to have some kind of mechanism for saving and loading a player's progress. BYOND provides a very simple language feature for this, the savefile. Savefiles can either exist on the host's machine, or on the player's. A design using savefiles on the host has a number of limitations. The first obvious limitation is that the saved progress cannot be easily shared between worlds. So for instance if a game has a number of servers running, a player's saved information is not readily available on all servers. In some cases this may be the desired effect, those servers could be largely different game scenarios for example. However it is not uncommon for a game to be running several identical servers, in order to provide a choice of low lag environments for their players. As such it would make sense that a player can access their characters on all servers.

As it is, BYOND offers functionality that will easily let a developer do this. Dantom.DB allows a game to connect to a MySQL server. This MySQL server can act as a central store for saved information. Naturally this is by no means the only way you could do it, although it is the way Naruto Universe intends to go about the problem. You could perhaps use Topic, or restrict your worlds to all being in the same directory on one machine. We see MySQL-based saving and loading as the best option because it scales. MySQL was built for thousands of queries a minute, several gigabyte databases, tables with hundreds of columns and so on. For developers who currently maintain games with large fan-bases or intend to create big world RPGs, MySQL makes the entire process of fetching and sending global information a lot faster. It doesn't require your worlds to be on the same machine as each other or indeed even on the same machine as the MySQL server.

Regardless of whether you choose MySQL or another method for sharing player data between worlds, there are a number of new problems you will have to address. In a single world, savefile based scenario things are quite easy. If the player is not logged in their savefile is not being used. If they are logged in then their savefile is in use from one place, the world they are in. Shared information introduces a new scenario. What happens if a player logs into two worlds at once? For MySQL, you can make use of some kind of locking mechanism. If you have a table that stores character information for example, you could create another table called 'locked' with just one column, the character's name. If the character's name is in the 'locked' table, the player is already using it and thus cannot load it on other worlds.

MySQL's ability to very quickly find matching information has benefits that extend beyond character loading and saving. Perhaps you are concerned about players impersonating each other, by picking identical names. When a player creates a new character, check their chosen name against the database for any matches. It's only a few lines of code and will execute a lot faster than trawling through 200+ savefiles for that information. If you're clever about it, then you can search for names that are like the new character's name, not just identical to it. Unfortunately, these benefits do come at a price. Using MySQL is not nearly as simple as reading and writing savefiles. For-instance there is a particular query language you need to work with, called SQL. Constructing queries in this format isn't exactly difficult, but it's by no means as simple as reading a datum out of a savefile.

MySQL offers RPGs a very solid way of sharing information between worlds. It will perform well, offers simple solutions to some of a game's more complex problems and it can easily be hosted via some shared web services. If you're thinking big, think MySQL. We sure are.
Awesome, a useful subject.

I really need to learn about MySQL saving :)
Nice article, it gave me a little inspiration to learn a little bit of SQL.
Yep, for my games I have my own personal lib which makes it easy for me to read/write from my mysql database, I use Topic() then I mess with the data sent, PHP+MySQL is my secret :p
Haywire wrote:
Yep, for my games I have my own personal lib which makes it easy for me to read/write from my mysql database, I use Topic() then I mess with the data sent, PHP+MySQL is my secret :p

If MySQL is installed on your server you can cancel out the middle man by using Dantom.DB and connecting to MySQL directly with BYOND itself.
Tiberath wrote:
Haywire wrote:
Yep, for my games I have my own personal lib which makes it easy for me to read/write from my mysql database, I use Topic() then I mess with the data sent, PHP+MySQL is my secret :p

If MySQL is installed on your server you can cancel out the middle man by using Dantom.DB and connecting to MySQL directly with BYOND itself.

Yeah I probably can, but I ALWAYS feel dirty using a libary, it just makes me loose hope in my projects!

Haywire wrote:
Tiberath wrote:
Haywire wrote:
Yep, for my games I have my own personal lib which makes it easy for me to read/write from my mysql database, I use Topic() then I mess with the data sent, PHP+MySQL is my secret :p

If MySQL is installed on your server you can cancel out the middle man by using Dantom.DB and connecting to MySQL directly with BYOND itself.

Yeah I probably can, but I ALWAYS feel dirty using a libary, it just makes me loose hope in my projects!

Its.. a library originally written by Dan as a wrapper for built-in functions that are completely undocumented. You're deliberately completely ruining the speed advantage in MySQL for absolutely zero benefit; you can't re-write the library yourself, and there would be no benefit because as said, its just a wrapper library.
Alathon wrote:
Haywire wrote:
Tiberath wrote:
Haywire wrote:
Yep, for my games I have my own personal lib which makes it easy for me to read/write from my mysql database, I use Topic() then I mess with the data sent, PHP+MySQL is my secret :p

If MySQL is installed on your server you can cancel out the middle man by using Dantom.DB and connecting to MySQL directly with BYOND itself.

Yeah I probably can, but I ALWAYS feel dirty using a libary, it just makes me loose hope in my projects!

Its.. a library originally written by Dan as a wrapper for built-in functions that are completely undocumented. You're deliberately completely ruining the speed advantage in MySQL for absolutely zero benefit; you can't re-write the library yourself, and there would be no benefit because as said, its just a wrapper library.

I now finally understand the full concept of the MySql library, cheers everyone.

NarutoGOA Uses MySQL, It is fantastic in every way possible. The lag of hosts is reduced significantly by the reduced need to access the harddrive, and the professional database MySQL setup is far more efficient for taking the saves and sending them off. Also we have been able to do lots of other cool things, including access player stats from webpages and graph player statistic trends such as the level distributions. We are also able to run MySQL queries that do mass functions such as respecs where people are refunded the levels they have used in situations of significant rebalance.

This is a great article and I really recomend this save system for any game that has ambitions of having more than 50 players.
Is there a way to get a "free" MySQL server? If not then poo on you >.<... Also, if your any kind of programmer you can advoid the whole mutlipul server entries problem easily and still have your own little base savefile server on someone's(perhaps your own) P.C.
Ss4toby wrote:
Also, if your any kind of programmer you can advoid the whole mutlipul server entries problem easily and still have your own little base savefile server on someone's(perhaps your own) P.C.

Hence why you use SQL, that savefile server will run faster. That was the point of the post.
Jeff8500 wrote:
Ss4toby wrote:
Also, if your any kind of programmer you can advoid the whole mutlipul server entries problem easily and still have your own little base savefile server on someone's(perhaps your own) P.C.

Hence why you use SQL, that savefile server will run faster. That was the point of the post.

Well, tipiclly you have to pay money for servers... I don't know about you but I don't have money to go throwin around just for some hobby of mine >.<.. Especially X amount of dollars a month..
Ss4toby wrote:
Jeff8500 wrote:
Ss4toby wrote:
Also, if your any kind of programmer you can advoid the whole mutlipul server entries problem easily and still have your own little base savefile server on someone's(perhaps your own) P.C.

Hence why you use SQL, that savefile server will run faster. That was the point of the post.

Well, tipiclly you have to pay money for servers... I don't know about you but I don't have money to go throwin around just for some hobby of mine >.<.. Especially X amount of dollars a month..

You don't have to pay. You can run it on your own computer, if you really want to.
Jeff8500 wrote:
Ss4toby wrote:
Jeff8500 wrote:
Ss4toby wrote:
Also, if your any kind of programmer you can advoid the whole mutlipul server entries problem easily and still have your own little base savefile server on someone's(perhaps your own) P.C.

Hence why you use SQL, that savefile server will run faster. That was the point of the post.

Well, tipiclly you have to pay money for servers... I don't know about you but I don't have money to go throwin around just for some hobby of mine >.<.. Especially X amount of dollars a month..

You don't have to pay. You can run it on your own computer, if you really want to.

Hmmmmm... I guess I still have ALOT to learn ^-^... Oh well, I have firewalls and etc. anyway so no need to bother with this stuff until later on in life..