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.
