Jump to content

  • Log In with Google      Sign In   
  • Create Account


Using a database in a game or just multiple objects?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
12 replies to this topic

#1 ChainedHollow   Members   -  Reputation: 158

Like
1Likes
Like

Posted 20 April 2013 - 09:35 PM

I'm working on a game in SDL and C++ with RPG aspects, such as stats, and gear. What I am confused about is how to implement so many different types of gear with different stats. Such as , should each different type of item be a new object in the programming, or should is it somehow possible to create a database I can use and update at later times when I want to add new items to the game. I've also heard about scripting and XML but I am just not sure where to go with this. (I'm still pretty new to all this, all I've done so far is Blackjack, tetris, and pong.)

 

Basically I just need a way to describe an item. Give it a name, what type of clothing it is(head piece, gloves, etc.), and what stat changes it provides. Then in the game be able to grab the information and use it to alter the player's stats. 

 

If someone can point me in the right direction I'm sure I can figure out some way to implement this properly. 

This is my first original game idea and I'm still in the planning stages really. Thank you for any advice and help!



Sponsor:

#2 C0lumbo   Crossbones+   -  Reputation: 2197

Like
4Likes
Like

Posted 21 April 2013 - 01:58 AM

If it's a one man project (i.e. you are the coder and you're also the person who's going to be setting the values for all your items), then personally, I wouldn't bother trying to do anything fancy with spreadsheets, XML or databases. I'd just define the tables of data directly in code. I would, however, make sure that access is strictly controlled through functions so that I could later on implement loading later on if it becomes worthwhile.

 

The moment you go data driven, there's a moderate amount of work writing code to load in your data files and to check for errors (missing fields, etc) which you can simply skip by keeping it simple. However, if you do decide to do it properly, then all approaches are fine, but I'd probably recommend using a spreadsheet, which you can save out as a .csv file (comma separated values), and load that in code. The loading code can be fiddly, but a spreadsheet is a reasonably nice way to view and edit your data, and you might find uses for formula functionality (e.g. calculating total cost of all your items to assist with balancing your economy).



#3 Satharis   Members   -  Reputation: 949

Like
0Likes
Like

Posted 21 April 2013 - 10:03 PM

Databases for games are a bit taboo unless you're talking like a dedicated server. Databases are just really bulky constructs designed for constant pulling and pushing of data like happens in an MMO or something, for a standalone game where you're just adding data you're not really going to be doing it on the fly so using just files would probably be best.

 

Keep in mind files are just data, if you're worried about simplicity of editing you can always design a tool for editing the files that mimicks what you would get from a database basically.

 

That said the above poster has some valid points, going file driven usually means writing up a fancy editor and data formats, it's -much- easier to put everything in code unless you're working on a team or something that needs immediate access to tweak data, or it's a particularly LARGE amount of items or something that you're editing on a regular basis.



#4 VladR   Members   -  Reputation: 722

Like
0Likes
Like

Posted 22 April 2013 - 11:54 AM

Basically I just need a way to describe an item. Give it a name, what type of clothing it is(head piece, gloves, etc.), and what stat changes it provides. Then in the game be able to grab the information and use it to alter the player's stats. 

 

Just use regular structures and enums.

Have one enum for type of the item : enum EObjectType {None=0, Weapon, Armour, Potion }

And have one struct that will keep all the relevant info about the item (whether it is a weapon, armour or potion):

struct SObject

{

  int ID; // global unique ID for the object - autoincrementing it, when filling up the internal DB is enough

  EObjectType ObjectType;

  .....

  int AddToStrength;

  int AddToDexterity;

  int AddToAccuracy;

  ...

  int RequiredStrength;

  int RequiredDexterity;

  int RequiredAccuracy;

}

 

Then, when using the item from the inventory, you just add those AddToStrength/Dexterity/Accuracy values to your stats values and you are done.

 

 

Personally, I am using text files for the database of the game objects. I wrote a very simple parser in an afternoon and never had to touch it since, so I guess it was a reasonable effort. This way, I can keep all my weapons, armours, potions in separate *.TXT files that are very easy to edit in Notepad.

 

When loading all items from the file, I just put them to a std::vector <SObject> Weapons, std::vector<SObject>Armour, std::vector<SObject> Potions. This way they are easy to work with (iterate, search, add/remove).

 

 

There is one more important advantage for having the "database" of items in TXT files - when you are testing, you will want to have multiple sets of these files so that you can test the different gameplay due to different objects/stats.

 

It will prove invaluable, when all the testers need to do, is just to replace the TXT files with a different set of TXT files. Even if that tester is just you.


Edited by VladR, 22 April 2013 - 12:08 PM.

VladR    My 3rd person action RPG on GreenLight:    http://steamcommunity.com/sharedfiles/filedetails/?id=92951596

 


#5 Serapth   Crossbones+   -  Reputation: 5312

Like
1Likes
Like

Posted 22 April 2013 - 01:38 PM

I would consider using JSON. There are a ton of parses available in dozens of languages, it's a simple format that solves many if the encoding files you could run into.

Think of JSON like a light weight ,vastly saner XML

#6 Blackarch   Members   -  Reputation: 526

Like
-3Likes
Like

Posted 22 April 2013 - 05:28 PM

Use http://www.sqlite.org/

 

Anybody telling you that databases for games in any capacity are "too heavy" or "taboo" doesn't have experience writing real-world performance-critical applications reliant on volumes of data that need to be organized in a coherent manner.

 

SQL Lite is going to solve your problem.


Software Engineer | Credited Titles: League of Legends, Hearthstone


#7 Kylotan   Moderators   -  Reputation: 3338

Like
5Likes
Like

Posted 22 April 2013 - 06:01 PM

SQLite is also going to cause several new problems, eg. how to get data into the database in the first place, and then how to get a row of loosely-typed data into a class or struct in your game. Once you write all the code to convert back and forth, you may find you've wasted a lot of time compared to just storing classes in a std::map.

#8 VladR   Members   -  Reputation: 722

Like
0Likes
Like

Posted 23 April 2013 - 07:50 AM

Use http://www.sqlite.org/

 

Anybody telling you that databases for games in any capacity are "too heavy" or "taboo" doesn't have experience writing real-world performance-critical applications reliant on volumes of data that need to be organized in a coherent manner.

 

SQL Lite is going to solve your problem.

Just because it is possible, doesn't mean it is actually a good idea.

 

I do happen to have the experience you are talking about and that is exactly the reason why I would never even think about it.

 

That is, of course, unless you are being paid by an hour and your goal is to make it take as long to implement as possible, so that you could invoice more.

 

Which, I think, is not the case here with the OP...


VladR    My 3rd person action RPG on GreenLight:    http://steamcommunity.com/sharedfiles/filedetails/?id=92951596

 


#9 Josh Petrie   Moderators   -  Reputation: 3110

Like
0Likes
Like

Posted 23 April 2013 - 09:06 AM

A database in the sense of a SQL Server installation or a MySQL installation would not only be massive overkill for your needs, but also wouldn't offer any compelling advantages over the simpler solutions in your case. I would take the approach recommended several times already and store all your item data in JSON text files. There are lots of great, simple parsers out there (such as picojson if you're using C++). A SQLite database may be a reasonable compromise between the two, but I still wouldn't recommend it in this case. It does not seem warranted.


Josh Petrie | Core Tools Engineer, 343i | Microsoft C++ MVP


#10 VladR   Members   -  Reputation: 722

Like
0Likes
Like

Posted 23 April 2013 - 10:16 AM

This is really funny.

 

We already spent more time arguing than it should take him to write a simple text parser smile.png


VladR    My 3rd person action RPG on GreenLight:    http://steamcommunity.com/sharedfiles/filedetails/?id=92951596

 


#11 markr   Crossbones+   -  Reputation: 1653

Like
0Likes
Like

Posted 23 April 2013 - 10:25 AM

Do the simplest thing that could possibly work. You will need some kind of serialisation if you intend to persist your stuff to disc.

 

You could use a third party serialisation library (boost is ok, I guess), or just write a really simple serialiser. It's up to you.

 

But don't make things more complicated than they need to be.

 

The use-case for a SQL database is mostly if you're storing a very large number of objects and don't want to keep them all in memory, but do want to use secondary indexes. Also interoperability.

 

If your database fits in memory, you plan to load it entirely in, and you don't want secondary indexing on-disc (if you don't know what this is, then you don't need it!) , then you probably don't need a SQL database.

 

Personally I'd probably write a really stupid serialiser that dumps things into text-files. Text files are really good because they're easy to debug.



#12 Serapth   Crossbones+   -  Reputation: 5312

Like
0Likes
Like

Posted 23 April 2013 - 01:15 PM

One thing I was really thinking about trying the next time I needed a lightweight persistence solution was to give Google's protocol buffers a shot.

 

It's pretty cool, example from wiki:

 

Message format:

message Point {
required int32 x = 1;
required int32 y = 2;
optional string label = 3;
}

message Line {
required Point start = 1;
required Point end = 2;
optional string label = 3;
}

message Polyline {
repeated Point point = 1;
optional string label = 2;
}

 

Then used in code:

 

#include "polyline.pb.h"  // generated by calling protoc polyline.proto (defined above)
 
Line* createNewLine(const std::string& name) {
  Line* line = new Line;
  line->mutable_start()->set_x(10);
  line->mutable_start()->set_y(20);
  line->mutable_end()->set_x(30);
  line->mutable_end()->set_y(40);
  line->set_label(name);
  return line;
}
 
Polyline* createNewPolyline() {
  Polyline* polyline = new Polyline;
  Point* point1 = polyline->add_point();
  point1->set_x(10);
  point1->set_y(10);
  Point* point2 = polyline->add_point();
  point2->set_x(10);
  point2->set_y(10);
  return polyline;
}


#13 Krohm   Crossbones+   -  Reputation: 3047

Like
0Likes
Like

Posted 24 April 2013 - 02:44 AM

I don't know if OP is still with us at this point anyway...

 

Basically I just need a way to describe an item. Give it a name, what type of clothing it is(head piece, gloves, etc.), and what stat changes it provides. Then in the game be able to grab the information and use it to alter the player's stats. 

 

If someone can point me in the right direction I'm sure I can figure out some way to implement this properly. 

There are two problems.

1st: a data structure must hold this data.

2nd: the data must get there.

While some people wrote about RDBMS (what?) an other about writing yet another domain specific language (c'mon), I'd rather consider the design problem first.

From your message, I have the impression you're considering examples... as a problem X instead of a problem Y. In generic terms. That's not the case. The first thing you must do is to sit down, and figure out what the game needs.

 

So, you have RPG elements. At the basic level say we deal about characters, stats and stat-boosting equipment.

An initial design might be (some fat trimmed and shortcuts taken)

struct Stat {
  String name;
  uint value;
  std::vector<StatModifier> effects;
  uint GetCurrentValue() const {
    uint ret = value;
    foreach(e : effects) ret += e.GetModifiers();
    return ret;
  }
};

class Character {
  std::vector<Stat> stat;
  Character() {
    stat.push_back(Stat(L"Strength", 10));
    stat.push_back(Stat(L"Hit points", 6));
  }
}

 

So, when equipping a pair of gloves giving STR+4 we look up for a "Strength" attrib and add a modifier.

Notice that an armor giving COS+20 would be wasted on a vampire as it has no "Constitution" attribute (not in D&D rule set at least).

You must resolve all the features you need to make your game work before starting to write. You don't need to figure them out in detail, but at least know in what direction you need to go.

For example, being copy-driven, the above method has an issue. If a specific object is disabled (say by enemy magic), what modifier do we need to change?

 

Notice at this point however, getting data there is rather straightforward. I suggest JSON to do that (it will take you a day). A JSON representation of the two objects above might be

gloves {
  "name" : "Empowering gloves"
  "attribEffects" : [
    { "str" : "4" }
  ]
}
armor {
  "name" : "Golem skin"
  "attribEffects" : [
    { "cos" : "20" }
  ]
}

 

I'm making this up right away so I cannot guarantee it will go through a proper JSON parser. But I'm confident it will, as JSON is so easy it will make you sick.

Now the problem is:

  • data to json: just iterate the various properties
  • json to data: more involved, must figure out the data structure to use, multiple data paths required.

I guess it's better to stop there now. This is a really open and complex problem, we could go on for ages.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS