Page 2 of 2
Re: Database/hosting help
Posted: Fri Mar 06, 2009 7:19 pm
by califdon
Confusion is the name of the game with databases! Look, it's not intuitive, you have to L-E-A-R-N how to do it. The way to start is by understanding what is meant by an entity. An entity is a thing or a person or an event or a transaction or a concept. Every entity that you want to represent in a database must have its own table. Each record in that table represents one instance of that entity. The fields in that table represent single-valued properties of that particular entity.
In your case, you've named many of the entities you want to represent: players, planets, civilizations. What else? You'll probably need tools, enemies, hazards, very likely others. Since I'm not into games, I don't know what else you would want. The point is, your database is going to be a model of the game world you're going to create. Relational databases can always be thought of as models of some real (or in this case, imaginary) set of entities that interact with each other. But the very first thing you must do is to identify the entities that you need to represent and their relationships to each other and their properties. When you've done that, and done it properly, and done it thoroughly, the rest of your project will mostly be some program logic and a lot of graphics.
Re: Database/hosting help
Posted: Fri Mar 06, 2009 8:05 pm
by LockNLoad
Calif - you sir, are the shiznit!! I think I am starting to understand now.
So EACH different object needs it own table...
EXAMPLE:
a fighter ship(a sort of weapon) will need its own table describing how much offense and defence and value, then it relates to how many 1 player has... am i getting this right?
If this is the case I am going to have hundreds of tables! WOW but I think I do understand it a lot better from the way you described it. I have read and read about relational databases but I never grasped how they would - relate- to my game until now.
THANK YOU!
More questions to follow I am sure!
Re: Database/hosting help
Posted: Fri Mar 06, 2009 10:03 pm
by califdon
I'm glad you're "beginning to see the light", as they say. Frankly, the vast majority of people never do.
Make sure that you understand that you don't need a table for every object, but for every entity that has a different set of properties. If a fighter ship is different (in terms of its properties) from other objects, it is a distinct entity and there must be a table to hold all the instances of fighter ships. So I doubt that you will need hundreds of tables, but you might have dozens or more fighter ships, each one represented as one record in the fighter ships table. Each one could have its own power or speed or color or tonnage--those would be records in the fighter ships table. Then you could relate a particular fighter ship (say, serial no. 24, with a top speed of warp 1.5 or a range of 17 lightyears) to a particular player, as the result of something-or-other. If the type of relationship is 1-to-1 (only one player can own a particular fighter ship at a time), one of the properties (fields) in every fighter ship record could be the primary key (ID) of the player that owns it. On the other hand, if each type of fighter ship might be owned by several owners simultaneously and each player could own several fighter ships, that's a many-to-many relationship, which requires a third table that has just 2 fields: the primary key (ID) of an owner and the primary key (ID) of a fighter ship type. To assign a fighter ship to an owner, you would add a record in the 3rd table with the appropriate ID's. To deprive (or destroy) an owner's fighter ship, you would delete the record in the 3rd table. See how this works?
Everything depends on how you decide what your entities are. For example, the entity might be "real" fighter ships (that is, each and every VIN no. is a record), so there would be a limited number of possible fighter ships to assign to players. Or you might decide that you just need to have 6 styles of fighter ships (different performance characteristics) and there's no limit to how many are active, you just need to know which kinds a player has at any time. In that case, you have defined the entity as classes of fighter ships and the table would contain only 6 records. Then your "3rd table" could relate as many players to as many types of fighter ships as you wanted.
These are not easy concepts, but they are what make it possible to do some heavy stuff with relational databases.
Re: Database/hosting help
Posted: Fri Mar 06, 2009 10:35 pm
by omniuni
Like Califdon said, relational databases can be incredibly powerful. I would love to tell you exactly how you need to lay out your DBs/Tables but I can't tell you too much, simply because I don't know the details of your game, but I think I can give you a push in a right direction, at least when it comes to users. I'll let Califdon tackle some of the crazier stuff that would eat me alive to try to think about... ("Fee, Fi, Foh... Fumi.... I smell a n00b named OmniUni....")
When you set up a database, you want to keep the individual data as separate as possible.
To start, you will need a table containing the users that are registered. Each user should have a unique ID that you use to identify them in the other tables. For example, if each user can create under their account some basic information about themselves, have a password, an avatar, age, gender, and other related information, you would create a second table that uses the user IDs from the first table as IDs to hold other information.
The way you might use this like so; If a user goes to log in, you search for their user name in the first (main) table of users. In this table, you can also check their password, to see if they've entered it correctly, and the status of their account (active, suspended, etc.) If everything checks out, you log them in and register their unique user ID. The fact that they are logged in, and some form of individual data is stored to the users browser in the form of a session or cookie.
As the "now logged in" page displays, you take that individual data and use their user ID to reference the rest of their personal account information on the other table I mentioned. Now, you can ask SQL to fetch for you information like their first and last name so that you can greet the properly ("Hello, Mr. User. Welcome back!") and maybe give them some useful information ("You last logged in a 371 days ago, and your character is now worth $0.04").
Unfortunately, before you go on, you need to work out a lot more about your game. You need to know exactly how your universe is going to be set up, how the different systems work, and all other sorts of details. Will there be taxes? Will there be different currencies? Are there different races, and can they interact (barter?) with one another, or just some other races? How does a user register, and how do they interact with the system? Are they presented icons? Text links? Forms? What information will they need to enter at each stage to play the game, and will that information be created from other users?
All of this information must go in the database somewhere, and I would STRONGLY recommend that you keep to an object oriented approach! If you don't you're going to end up with scripts as long as the yellow brick road, and just about as nonsensical!
-OmniUni