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'm just about to engulf myself in an MVC-based/Component architecture in C#, using MySQL's connector/Net for the data storage, and probably some NHibernate/FluentNHibernate Object-relational-mapping to map out the data structure. The goal is to build a scalable 2D RPG.

Then I think about it...and I can't help but think this seems a little "heavy weight" for a 2D RPG, especially one which, while I plan to incorporate a lot of functionality and entertaining gameplay, may be ported to something like Windows Phone or Android in the future.

Yet, on the other hand even a 2-Dimensional RPG can become very complicated, and therefore must incorporate a lot of functionality. While this can be accomplished with text/XML/JSON for data storage, is there a better way? Is something such as Object-Relational-Mapping useful in such an application?

So, what do you think? Would you say that there is a place for such technologies? I don't know what to think...

share|improve this question
    
"may be ported to something like Windows Phone or Android in the future." Well I think you first need to nail down your platforms you want your engine to support. You can't write games in C# for Android, for example (unless you count using Unity). –  Tetrad Nov 26 '11 at 10:23
    
Also: gamedev.stackexchange.com/faq#dontask You should only ask practical, answerable questions based on actual problems that you face. avoid asking subjective questions where "we are being asked an open-ended, hypothetical question: “What if ______ happened?”" –  Tetrad Nov 26 '11 at 10:25
    
What is a "light based" game? Will it be your first game? –  Den Nov 26 '11 at 11:38
1  
I recommend you read about "ORM: the Vietnam of Computer Science": codinghorror.com/blog/2006/06/… -- it's not worth it for anything complicated. –  ashes999 Nov 26 '11 at 14:05
2  
Besides the criticisms about the details of the question, it's still a good question and has fortunately got an answer that hopefully nailed the ORM coffin shut for the forseeable future. That is, until that zombie breaks out.. –  bobobobo Nov 27 '11 at 0:44

1 Answer 1

up vote 9 down vote accepted

If you think a 2D RPG is so complicated that you not only need a database, but also a ORM to simplify the interfacing to that database, then I'd suggest you probably haven't yet studied the game mechanics yet. Do bear in mind that we had Zelda in the cartridge era where you might have had 256 bytes of battery-backed RAM to save the current state of the game and only a few KB of RAM to store the state of the game world during runtime. How much more complex than Zelda is your game going to be?

OK, here's another example: Have you played World of Warcraft? This is a pretty complex game with 10 playable classes and hundreds of spells just for the players. Mobs and bosses have their own spells/abilities and many items also have their own effects. And yet underneath everything combat related resolves down to a small number of attributes (health, mana, energy, etc.), cooldown timers and a system of buffs/debuffs. Inventory items are just a type for the item and a quantity. Quests have an identifying number, the player keeps a record of quests completed and their quest log just tracks the id of the quest and optionally a counter of how many kills (or whatever) they've performed towards its completion.

You can store all that stuff in a database of course (and WoW does in fact), but for a single player game there's little enough data that you can afford to store the current state of the game in memory and just serialize it out to a file whenever it needs to be saved. Data that doesn't change can either be coded into the executable itself or deserialized from files as needed. Because structurally it's all very regular it shouldn't take long even if you were writing the serialization/deserialization functions by hand.

Oh, and personally I think ORMs are like 10,000 spoons when all you need is a knife. They either get in the way because the way SQL databases work just isn't a very good fit for the representation of that data as objects, especially when it comes to the update/delete side of things. Or, as I assume the case is with you, you only use them to give persistence to your objects, in which case carrying around the weight if a SQL database, even one as small as SQLite is a waste and the extra complexity of the ORM's API compared to just using plain old objects in memory and saving them to a plain old file isn't justified.

share|improve this answer
    
I appreciate your answer. Consider this thread solved. –  blissfreak Nov 26 '11 at 23:02
1  
+1 for the good answer, you Alanis fan you –  bobobobo Nov 27 '11 at 0:42
1  
Fantastic answer. As a .NET/SQL server monkey, I'm constantly amazed by how many developers hide behind an ORM instead of figuring out how an inner join works. Kudos. –  David Lively Nov 27 '11 at 2:46
    
+1 for good answer, but more for 2 very good examples! –  Mentoliptus Nov 27 '11 at 11:09

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.