8
\$\begingroup\$

I'm creating a small text RPG as a way to practice python and I'm running into a question about how to load data. The game is a wild west game, though that isn't too relevant, and I need to store lists of weapons and their properties, as well as lists of characters, scenarios, etc. I've got a good idea of how to represent this data as classes but I'm not as clear on how to store and load the data.

My main question revolves around the relationship between data and classes. I have read through some posts here on SE and many of them relate to storage, so I have some good information there.

When should I load that data in? For example, the player chooses from several weapons when the game starts. Should I load in all the weapons and instantiate all the weapon objects at that point? Should the weapon class have the ability to show weapons from the database without instantiating them?

Thanks for any help.

Improve this question
\$\endgroup\$

4 Answers 4

Reset to default
7
\$\begingroup\$

Since you say a "small" text RPG, my advice would be to just preload everything. If we're not talking about an enormous amount of content, then it shouldn't make a great difference to startup time, and it keeps things, as Bjorn advises, simple.

One thing that occurs to me, reading your question, is that you may want to consider the difference between a weapon and a weapon type. My preference is always to have a clear distinction between the two, and to have both modeled in code so that I can ask questions about the weapon type without necessarily having to have an instance on hand. (One way of doing this is to have the weapon type be the class, with class methods that allow you to interact with it, and the weapon be an instance of that class. I actually do not prefer this approach because then it's either impossible or incredibly messy for a weapon to change type. Obviously that won't be relevant to all games.)

Improve this answer
\$\endgroup\$
4
  • \$\begingroup\$ How would you differentiate these in code? I have indeed run into this problem. \$\endgroup\$
    – timfreilly
    May 5, 2011 at 1:20
  • 1
    \$\begingroup\$ The way I have it is that the weapon types are objects managed through the "brokered definition set" pattern that I talk about in this SO question: stackoverflow.com/questions/401720/…, and each weapon object knows what type it is via an ID code. So you might do obj->setWeaponType(WEAPON_TYPE_SHOTGUN) or whatever, and the weapon configures itself appropriately. Weapon performance metrics might use the type's values as a baseline but allow the final result to be modified by the instance. That sort of thing. \$\endgroup\$
    – chaos
    May 5, 2011 at 3:22
  • \$\begingroup\$ That's something to think about, thanks for the link. What would you do in a situation where you wanted to display a list of the available types of weapons? Does that sort of request go through the broker/type version? \$\endgroup\$
    – timfreilly
    May 5, 2011 at 3:37
  • 1
    \$\begingroup\$ @timfreilly: It depends on context. If it's something like a shop, I would usually have the place stocked with actual instances of weapons and display their descriptions to the player. If it's something like a developer overview or help interface, then I would ask the broker daemon for the full set of weapon type definitions and display information on them. \$\endgroup\$
    – chaos
    May 5, 2011 at 5:17
4
\$\begingroup\$

Load everything at the start. Don't complicate your program by splitting data between memory and disk unless you have to (eg. when there is too much to hold in memory at once).

The important thing is to understand the distinction between data that represents instances of an item and data that represents the type of an item. Generally several instances of the former share one common instance of the latter.

Improve this answer
\$\endgroup\$
4
  • \$\begingroup\$ I could use some additional information there. How to you code this difference? \$\endgroup\$
    – timfreilly
    May 5, 2011 at 1:24
  • 1
    \$\begingroup\$ @timfreilly: I have a sample class hierarchy for an item system like Kylotan describes at gamedev.stackexchange.com/questions/4516/…; this is often called the flyweight pattern. \$\endgroup\$
    – user744
    May 5, 2011 at 9:16
  • \$\begingroup\$ As Joe says, the Flyweight pattern is one way to present this, by implicitly sharing that 'type' data across the instances. I personally prefer to represent them explicitly, eg. with a MonsterInstance class and a MonsterType class. Each instance of MonsterInstance has a reference to its relevant MonsterType instance. \$\endgroup\$
    – Kylotan
    May 5, 2011 at 12:23
  • \$\begingroup\$ (I'd do what Kylotan says as well, I'd still call that a flyweight object.) \$\endgroup\$
    – user744
    May 6, 2011 at 14:28
0
\$\begingroup\$

I'm not that very familiar with python. The general advice I would give is to keep it simple. You said that you already got an idea of how to represent the data. If you got some classes for the data you want to store, you can store them in a list. That list can then be serialized to disk onSave and deserialized onLoad. For a first implementation and if the data is not that big I would load everything on start of the game and save it at some given points in time.

Improve this answer
\$\endgroup\$
0
\$\begingroup\$

You could use SQLite. Using SQLite, you can create databases in memory and on the hard drive, and you don't need a giant DBMS like MySQL installed.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .