RP Character System with MySQL, most efficient way?
#1

Hello, everyone.

Well I've been trying to rattle my brain on how to create a character system for my RP server that is efficient and doesn't cause lagg/stress on the server... My plan was to allow players to have a main account which inside contains probably a maximum of 3-5 character accounts...

Problem is I have a rough idea how I could have each individual characters data saved in the database but I don't know if it's an efficient way. My idea was to have separate data fields for every character for example... if I was saving a position of the characters, in the database make it like.

Код:
Char1Posx (FLOAT)

Char1Posy (FLOAT)

Char1Posz (FLOAT)

Char2Posx (FLOAT)

Char2Posy (FLOAT)

Char3Posx (FLOAT)

Char3Posy (FLOAT)

Char3Posz (FLOAT)
Meaning that the players character ones position is saved within Char1Pos(X, Y, Z). Character two is in the Char2Pos etc etc...

Personally I feel that's too much effort or even just a messy way to code it and eventually if enough players are on will cause major lag...
Does anyone have another solution to how I could do this? is there a way I could possibly set an array of floats in the database that could store all their characters floats in the same field, or is the way I've done it the best or maybe even the only way?

Thanks in advanced to your replies and help!
Reply
#2

****** put it very simply and he's absolutely right. Actually, I have a similar system, I set it up like this.

Table for the master accounts, meaning the account the player logs in with.
Table for all the characters, the master account table has an ID associated with the account, this ID is also used in the character tables to decide which characters belong to a player. When the player logs in using his master account it presents him a dialog with all his characters. This way you have no virtually no limit on the amount of characters. (your way is using SQL incorrectly, you are then focussing on the weak points instead of what it is designed to do ).

Using table relations you can link the two tables together so when you delete one it doesn't cause a dead link. If you need an example, just tell me but I recommend you to search some of the terms on ******.
Reply
#3

Quote:
Originally Posted by ******
Посмотреть сообщение
Use a separate table with just "owningplayerid, characterid, x, y, z". Don't use multiple columns in a single table to try emulate what SQL is already good at!
Ah so pretty much... Where you mean owningplayerid i'd place the master account name there? So use a different table?
I knew the way I was doing it was wrong and not using SQL right but I thought i'd put my side of the plan out there just to let you guys try understand what my problem was... I don't know why, but I never even thought of a new table. Thanks again ****** & Playbox!
Reply
#4

Quote:
Originally Posted by LiamM
Посмотреть сообщение
Ah so pretty much... Where you mean owningplayerid i'd place the master account name there? So use a different table?
I knew the way I was doing it was wrong and not using SQL right but I thought i'd put my side of the plan out there just to let you guys try understand what my problem was... I don't know why, but I never even thought of a new table. Thanks again ****** & Playbox!
Yes, you could use anything that you could use to identify the players main account with. However I recommend you use ID's instead of the name for the master account instead, you would then use that ID in the owningplayerid.

For example you could create an integer called ID with Auto Increment and Primary ticked on, this is common practice and used often. (not saying it's the best, I haven't stayed up to date so someone else may have a better quote on this).
Reply
#5

Quote:
Originally Posted by playbox12
Посмотреть сообщение
Yes, you could use anything that you could use to identify the players main account with. However I recommend you use ID's instead of the name for the master account instead, you would then use that ID in the owningplayerid.

For example you could create an integer called ID with Auto Increment and Primary ticked on, this is common practice and used often. (not saying it's the best, I haven't stayed up to date so someone else may have a better quote on this).
On the idea of using the Auto Increment... Setting it as an INT, what would be the range I should use for the INT? 11 is set by default but that's too low right?
Reply
#6

No, the 11 just represents padding. An INT is always 32 bits. Meaning you can store values up to 4 billion and something (unsigned).
Reply
#7

I would go with ******'s solution and make a seperate character table which complements the user table. If you know SQL moderately you could even consider (inner) joins.
Reply
#8

If you delete data is there a way to move the unique ID back down? For example if someone had an ID that was 7 and the next one was 8...

If I delete the data with the ID 8... and create a new one.. it goes to 9... is there a way to put it back to 8? Because now the ID's go 6, 7, 9 in sequence.
Reply
#9

If you mean in the database? You can (re)set the AUTO_INCREMENT index using PhpMyAdmin or talking SQL to your server:
Код:
ALTER TABLE table_name AUTO_INCREMENT = 1;
Reply
#10

Quote:
Originally Posted by Sithis
Посмотреть сообщение
If you mean in the database? You can (re)set the AUTO_INCREMENT index using PhpMyAdmin or talking SQL to your server:
Код:
ALTER TABLE table_name AUTO_INCREMENT = 1;
Cheers mate, apoligise for the late reply. I've been busy with other programming projects for college.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)