Dev Diary # 7, Database Lovin'
by Gareth Fouche · 02/17/2006 (2:56 am) · 2 comments
I was talking about my stats system last time, and how I'd been making progress with that. Well, I got the basics working, players physical stats like strength etc, and was looking into adding player skills.
I wanted a generic way to add skills, set up what they did, update them etc. It's a bit more complicated doing it in code, and was much uglier than I liked. I could hardcode some skills, but I wanted it done in such a way that I could easily modify or add new skills at I built up my game.
So I started looking through the resources for inspiration, and started reading Dreamers MMORPG tutorials. I'd glanced over them before, not really digging deep because I wasn't making a MMO, but the second time through, in light of the issues I was working on, I read them properly, and really liked what I saw. Using a databse to store stats and skills and inventory (and a huge number of other things) is so much simpler and easier to use, as well as much cleaner. I know its probably already obvious to some people, but in a game as data driven as an RPG, databases are a huge boon. Reinventing the data management wheel is pointless.
To be honest, I hadn't wanted to look at databases. I'd imagined that there would be setup to be done, and licensing issues, and I didn't want the hassle. But I looked at the SQLite resource Dreamer recommends, and was delighted to find its got almost no setup (add the files to project, put dll in directory) and the licence lets you use it for whatever you like, no royalties or anything.
Now its easy to setup skills, I just make a table for them, and if I want to add in new skills, or change the structure of the skills, I can just adjust the table and maybe the little bit of script that reads it. Much easier than changing program code and recompiling.
The second advantage I found is to do with the fact that my game is single player. It had bothered me in the past, when I was using a c++ code solution, that there would be 2 copies of the data, one for the client and one for the server, even though they're both running on the same machine. With a DB, I can have them both just access the same one, and viola, no info duplication. I also don't have to send alot of the data back and forth that I used to. Say the client wants to modify his stats. I used to have to send all the modified stats to the server through messages. Now the client can just write them to the DB, send a "statsUpdated" message, and the server can read the DB to see the changes.
Anyway, I am loving the DB approach, and am going to be replacing a lot of the things I've already done in code with DB tables. Inventory, Spells, Spellbook, Dialogue, Journal etc. I'm also going to use the DB for persistance, saving out the game state etc. I plan to use two databases during a game. The "core" database stores all the game rules, the things that wont change from game to game, progression tables and item stats and spells and creature attributes etc. The second DB stores tables relating to the current games status, current player stats, quest flags set , player inventory etc. Both client and server will access both these tables. For example, when the player views his inventory, he will look at the "current" DB to find what items he has, but when he wants to see what the stats of an item are I'll do a search into the core DB for said items attributes. Saving the current game will mean making a copy of that "current" DB, loading a game will mean copying the saved DB and using the copy as the "current" DB. I hope that made sense. ;P
Not only does this make it easy for me to tweak parameters for my game rules, it opens up modding possibilities. Anyone with a bit of knowledge of SQL can go in, read the tables, change the parameters, add new items etc, and viola, a customised experience. Heck, I am thinking of making an in-game DB editor using TGEs guis, to make life simpler for myself, but combined with the existing TGE editors that would make for a tool like Morrowinds Construction Set! This does allow for cheating, but so what? If they've bought the game, let them. And being able to easily mod a game adds immensely to its appeal to a lot of people, just take a look at the Morrowind sites out there, the game is 4 years old and mods are still released for it every week. It also makes it easy for me to release patches, in the form of database updates and tweaks.
So, while this new development means I need to go in there and tear out most of my old code, code I spent weeks working on, I'm excited by the possiblilities. Ah well, such is the life of a programmer.
I wanted a generic way to add skills, set up what they did, update them etc. It's a bit more complicated doing it in code, and was much uglier than I liked. I could hardcode some skills, but I wanted it done in such a way that I could easily modify or add new skills at I built up my game.
So I started looking through the resources for inspiration, and started reading Dreamers MMORPG tutorials. I'd glanced over them before, not really digging deep because I wasn't making a MMO, but the second time through, in light of the issues I was working on, I read them properly, and really liked what I saw. Using a databse to store stats and skills and inventory (and a huge number of other things) is so much simpler and easier to use, as well as much cleaner. I know its probably already obvious to some people, but in a game as data driven as an RPG, databases are a huge boon. Reinventing the data management wheel is pointless.
To be honest, I hadn't wanted to look at databases. I'd imagined that there would be setup to be done, and licensing issues, and I didn't want the hassle. But I looked at the SQLite resource Dreamer recommends, and was delighted to find its got almost no setup (add the files to project, put dll in directory) and the licence lets you use it for whatever you like, no royalties or anything.
Now its easy to setup skills, I just make a table for them, and if I want to add in new skills, or change the structure of the skills, I can just adjust the table and maybe the little bit of script that reads it. Much easier than changing program code and recompiling.
The second advantage I found is to do with the fact that my game is single player. It had bothered me in the past, when I was using a c++ code solution, that there would be 2 copies of the data, one for the client and one for the server, even though they're both running on the same machine. With a DB, I can have them both just access the same one, and viola, no info duplication. I also don't have to send alot of the data back and forth that I used to. Say the client wants to modify his stats. I used to have to send all the modified stats to the server through messages. Now the client can just write them to the DB, send a "statsUpdated" message, and the server can read the DB to see the changes.
Anyway, I am loving the DB approach, and am going to be replacing a lot of the things I've already done in code with DB tables. Inventory, Spells, Spellbook, Dialogue, Journal etc. I'm also going to use the DB for persistance, saving out the game state etc. I plan to use two databases during a game. The "core" database stores all the game rules, the things that wont change from game to game, progression tables and item stats and spells and creature attributes etc. The second DB stores tables relating to the current games status, current player stats, quest flags set , player inventory etc. Both client and server will access both these tables. For example, when the player views his inventory, he will look at the "current" DB to find what items he has, but when he wants to see what the stats of an item are I'll do a search into the core DB for said items attributes. Saving the current game will mean making a copy of that "current" DB, loading a game will mean copying the saved DB and using the copy as the "current" DB. I hope that made sense. ;P
Not only does this make it easy for me to tweak parameters for my game rules, it opens up modding possibilities. Anyone with a bit of knowledge of SQL can go in, read the tables, change the parameters, add new items etc, and viola, a customised experience. Heck, I am thinking of making an in-game DB editor using TGEs guis, to make life simpler for myself, but combined with the existing TGE editors that would make for a tool like Morrowinds Construction Set! This does allow for cheating, but so what? If they've bought the game, let them. And being able to easily mod a game adds immensely to its appeal to a lot of people, just take a look at the Morrowind sites out there, the game is 4 years old and mods are still released for it every week. It also makes it easy for me to release patches, in the form of database updates and tweaks.
So, while this new development means I need to go in there and tear out most of my old code, code I spent weeks working on, I'm excited by the possiblilities. Ah well, such is the life of a programmer.
About the author
Recent Blogs
• SoW Weekly Update 10• SoW Weekly Update 9
• SoW Weekly Update 8
• SoW Weekly Update 7
• SoW Weekly Update 6
#2
03/18/2006 (10:26 pm)
I have been designing a single player RPG in the last month and getting into the coding aspect of it in the last week. Your posts were a good read for doing this.
Torque Owner Prairie Games
Prairie Games, Inc.