How do you ...?

[Bikkebakke]

Hello, there!

 

I'm coding a browser-game and I'd need to add skills and items soon but I can't figure out how and where to store the character information when it comes to skills or items?

 

It'd be awful if I had to add a seperate field in the user table for every single skill and item I'm going to implement as the field numbers could reach hundreds pretty easily.

 

I figured I could code a script to write the information in a file when the player gets an item or learns a skill but does it get too complicated when the script has to add a certain piece text when a player learns a new skill BUT if the player further trains the skill he/she has already learned the script would have to modify the before written text to replace the skill level, damage modifier etc. effect?

 

Or is there a better way to do this? 

 

Thanks in advance!

[KevinM1]

Hello, there!

 

I'm coding a browser-game and I'd need to add skills and items soon but I can't figure out how and where to store the character information when it comes to skills or items?

 

It'd be awful if I had to add a seperate field in the user table for every single skill and item I'm going to implement as the field numbers could reach hundreds pretty easily.

 

I figured I could code a script to write the information in a file when the player gets an item or learns a skill but does it get too complicated when the script has to add a certain piece text when a player learns a new skill BUT if the player further trains the skill he/she has already learned the script would have to modify the before written text to replace the skill level, damage modifier etc. effect?

 

Or is there a better way to do this? 

 

Thanks in advance!

 

Sounds like you didn't really spend enough time designing your game's data storage and representation.

 

Ideally, something like this would be split into multiple tables, and maybe even some XML files.  If you normalize your DB scheme, you can easily map player characters to skills and items (and vice versa).  Here's a link to get you started: http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html

 

I find that game design is a bit easier if you use OOP.  Many in-game entities (items, weapons, spells/attacks/abilities, the characters and enemies themselves, etc.) map naturally to objects, and from there, to db tables.  It just seems clearer that way, but YMMV.  Just throwing it out there.

[Bikkebakke]

Sounds like you didn't really spend enough time designing your game's data storage and representation.

Yea I really didn't, this is the very first thing I've ever coded, a kind of learning project.

 

I'll take a look at the link you posted. 

[Bikkebakke]

I finished reading the page you linked.

 

If I didn't miss a vital point in the article, it wasn't really the problem here.

 

I was going to create a seperate table with the skill data and link it with the user table but I don't want to add a field for every single item/skill to store the skill level or item amount each player has.

 

But it seems it's the only solution I can think of, so I'll just go with that. :3

[KevinM1]

I finished reading the page you linked.

 

If I didn't miss a vital point in the article, it wasn't really the problem here.

 

I was going to create a seperate table with the skill data and link it with the user table but I don't want to add a field for every single item/skill to store the skill level or item amount each player has.

 

But it seems it's the only solution I can think of, so I'll just go with that. :3

 

Don't add fields, add records.

 

Every item should have a uniform structure, correct?  Something like name, cost, value, etc.  Make one table with that, and populate it with all your items.

 

Now, make another table.  This one will link the character to their items.  How?  By matching item ids with character ids.  Why?  Because the relationship is many-to-many.  Many different characters can own the same items.  Many items can be owned by the same character.  Do the same thing for abilities - one table that contains ability data, and another that links characters to them.

 

Also, reread the article.  If you go through the normal forms, you'll see these kinds of relationships occur naturally as you go through the progress.

[Bikkebakke]

Ah, yes now I understand!

 

I just don't recognize the english names as we use finnish clients when working with databases at school.

(That's also why it took me half an hour to read trough the article  )

 

I get the basic idea now, but I still can't figure how to set up the database.

 

Am I correct if I assume I'm going to have 3 tables: users table, items table and an extra table that links the player(s) to the item(s)?

 

How do the 'records' work?

 

Sorry for all the hassle and tons of questions but this is the kind of thing you're going to have a hard time learning on your own.

[Orionsbelter]

Erm i think i know what you need but i don't really know alot about the function, the function is explode() you have like a field called skills and the value like 0-1-3-2 so say the first number is their running skill which is 0 the next is their punching skill which is level 1 the next is their flying skill which is level 3 and the last is their driving skill which is level 2 do you follow?

[Bikkebakke]

Yea I follow, but there is going to be over a hundred skills, I just need a way to store the skill level for the char and I think it'd be too complicated to implement them that way. :/

[KevinM1]

Ah, yes now I understand!

 

I just don't recognize the english names as we use finnish clients when working with databases at school.

(That's also why it took me half an hour to read trough the article  )

 

I get the basic idea now, but I still can't figure how to set up the database.

 

Am I correct if I assume I'm going to have 3 tables: users table, items table and an extra table that links the player(s) to the item(s)?

 

How do the 'records' work?

 

Sorry for all the hassle and tons of questions but this is the kind of thing you're going to have a hard time learning on your own.

 

Ah, okay.  Yeah, the language barrier can make things a bit more difficult to get through.

 

You're going to have 5 tables in total:

 

The user/character table, which contains fields that relate to what a user/character should be.  So, this would include their name, hit points, and/or whatever else you need.

 

The items table, which will contain fields that describe the attributes of the items in your game.  Again, things like the item's name, its value, how much it would cost in a store, and/or other attributes.

 

The items-to-user/character table.  This is a very simple table.  Ideally, you'd have three fields - the primary key/id for each row, the user/character id, and the item id.  With this table, you map characters to items (and vice versa) via their ids.  A couple of example rows:

 

ItemsToUserId             UserId             ItemId
0                         45                 55
1                         45                 98
2                         45                  2
3                         23                 55
4                         23                 49
5                         52                  9
6                         77                 37

 

User 45 has items with the ids of 55, 98, and 02.  User 23 has items 55 and 49.  I hope this makes sense.

 

A table for abilities.  This should be straightforward.

 

A table that maps abilities to users/characters, which should essentially be the same as the ItemsToUsers table.

 

So, with this sort of setup, instead of adding fields to your existing tables when a user gets a new item or skill, you add records (rows of data) to these new tables that exist solely for the purpose of maintaining these relationships.  It keeps your data intact and your table structure sound while giving you the flexibility to add/edit/remove skills and items.  This is, in fact, why MySQL is called a relational database.

[Orionsbelter]

Yes but the way would be easier of the database load. Be care how you do this as a table with over 100 fields can be hard on your database storage. Be sure that also only set the correct size of each field. .

 

P.S. what are you doing? are you wanting people to sign up to play and their player has over 100 skills in which then need to do tasks in order to increase their skill levels?

[Bikkebakke]

P.S. what are you doing? are you wanting people to sign up to play and their player has over 100 skills in which then need to do tasks in order to increase their skill levels?

Theres going to be over 100 skills, the player decides the class and build and develop their characters and as they develop they unlock new and better skills to obtain, one player can never get every skill (and they don't need to because the way the character is built determines which skills are good and which most likely useless)

 

 

@Nightslyr, a thousand thanks! I'll start working right now!

Sorry for consuming your precious time.

 

(And lol at my "How do the 'records' work?" question, I didn't know the rows are called records *feels dumb*)

 

EDIT:

The item buy script runs a mysql_query script, that goes something like:

$insert_item = "INSERT into `users_items` (`item_id`,`user_id`) VALUES ('$item_bought','$playerid')";
mysql_query($insert_item);

Am I on the right road here?

 

[KevinM1]

@Nightslyr, a thousand thanks! I'll start working right now!

Sorry for consuming your precious time.

 

Well, that's why I'm here.