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 ?

  • \$\begingroup\$ In general, we ask that you only ask one question, per "question" \$\endgroup\$
    – Jesse Dorsey
    Sep 15 '11 at 17:16
  • \$\begingroup\$ 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. \$\endgroup\$ Sep 15 '11 at 18:16
  • \$\begingroup\$ 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. \$\endgroup\$ Sep 15 '11 at 19:21
  • \$\begingroup\$ 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. \$\endgroup\$ Sep 16 '11 at 12:53
  • \$\begingroup\$ 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. \$\endgroup\$
    – bummzack
    Oct 30 '11 at 12:23

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. ( ;


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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