Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I've had the idea of creating a webgame for a while now, and as it becomes more and more accurate i started playing around with Symfony 2.0.

First question :

it seems that it is recommanded to use Doctrine2 (ORM) to manipulate database with Symfony, but i'll feel more comfortable with pure SQL. Am i wrong ?

Second question :

The game i'm thinking of is somewhat a kind of RPG, with the classic character, stats, inventory, etc.

I have some notions of SQL, and i'm improving my knowledge of it at school right now (though i deplore they only teach us oracle environment), but there's a point i need to discuss : How would you modelise the character's inventory ? Is a noSQl databse (mongoDB) usefull here ?

share|improve this question
    
In general, we ask that you only ask one question, per "question" –  Noctrine Sep 15 '11 at 17:16
    
Yup i'm sorry, but i think the two questions are related because the choice of SQL/Doctrine/noSQL will influence the way to design the database, and thus the inventory. –  teh internets is mad of catz Sep 15 '11 at 18:16
    
What kind of RPG are you developing that you feel the need to use a true database of any kind? Unless you're talking about an MMO, databases are generally overkill. –  Nicol Bolas Sep 15 '11 at 19:21
    
By web-based RPG i mean a game where people register to have a character and play with the other players, in the same virtual world. –  teh internets is mad of catz Sep 16 '11 at 12:53
    
What makes you think noSQL is a better approach for an inventory? Your question(s) don't ask to solve a given problem but rather ask for opinions and debate. –  bummzack Oct 30 '11 at 12:23

1 Answer 1

up vote 3 down vote accepted

I don't have the exact answers you're looking for, but I'll just lay some options out there.

  1. I'm biased, but I would say that you definitely want an ORM instead of dealing with SQL directly.

    • If you're into the whole OOP thing, then an ORM gives you an object-oriented view of your data, which is usually more helpful than manually pulling data out of rows and stuffing it into records in some weird, custom way that gets smeared all over your sprawling game architecture. Centralize your storage access and Don't Repeat Yourself.
    • A well-written ORM layer gives you a lot of flexibility down the road if you need to switch DB platforms (Oracle to PostgreSQL, or something).
    • You will, inevitably, need to write custom SQL at some point. That's okay, it doesn't mean the concept of ORM is faulty... it's just not an airtight abstraction.

    Check out this article on the "Active record pattern" to see what else it gives you. It's a very common architectural pattern for writing ORMs.

  2. As far as modeling a character's inventory, you'll probably end up with something like this: make Characters, Items, and ItemTypes tables. Each row in Items has the primary key of the row in Characters that the item belongs to (Targ, the barbarian, has this particular sword). Items also has the primary key of a row in ItemTypes corresponding to the type of item it is (this sword item is of type sword).

    That might not be parseable as English. What I mean is, you don't want to duplicate the attributes of the sword item across every character, monster, and dungeon in the world. You're probably much better off making every individual sword item point to a "sword type" and then, when you need to adjust the attributes of swords (and you will), you can change it in one place and BAM, it's changed everywhere.

    You could extend this to the characteristics of items as well: maybe "of Lightning" is a characteristic that can be added to lots of stuff: weapons, armor, clothes, whatever. So, "of Lightning" gets its own row in the SpecialTypes table and your lowly sword, from the Items table, now points to "of Lightning". BAM, one Sword of Lightning coming up.

    That all makes more sense if you're modeling this stuff relationally. If you were going the NoSQL route, then you might be better off denormalizing everything into the character object. But I'll let someone else tackle that. ( ;

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.