Hm, although I don't know enough to give you an answer, I hope somebody who has the knowledge will provide a thorough answer for this as it will definitely help me in my current game.

Well, as the posters above pointed out, if you want different classes of item, virtual functions are probably a big part of the answer. Using them you should be able to specify the functions that you expect an inventory object to use in teh base class, but only implement them in the child classes.

The form is something like this:




You could then do something like this:



The correct child version of the virtual function should be executed in each case.

If you want to know what type of object was called, include a virtual function that returns the type of object that it represents, such as:



However, there is another question that I would like to ask: Are you sure that you want to create separate classes for different types of inventory item? I daresay that it can be very useful (I can see it being used for such items as Ultima VIII's keyring item, for instance, which acted in a different way to other inventory items), but is it really called for in your case?

What about storing the object's information, and perhaps scripts for its interactions with the world, in a single object. Include a name variable with which to identify the object, for example, and perhaps which actions it can be used with.

A very simple version might have something like this:



In this case, I presume that you would somewhere have enumerations that specify the actions and scripts that are allowed. When the player attempts to do something with the item (such as hitting someone with it), simply check the requested action against those specified in the valid_actions vector and, if it is there, perform it with that item, and otherwise tell the player that they are a silly player and that, for instance, they are not allowed to hit people with bottles of expensive magical elixirs.

This system could of course also be extended to allow parameters for the scripts, to, for example, specify how much health to deduct from the player.

Note that in the cases of such things as axes and swords, you might want to make the actual wielded weapons different to inventory weapons, or have their script simply set the "current weapon" statistics appropriately, depending on how you are handling such things, instead of creating separate classes to allow for different abilities.

Quote:Original post by Thaumaturge
Well, as the posters above pointed out, if you want different classes of item, virtual functions are probably a big part of the answer. Using them you should be able to specify the functions that you expect an inventory object to use in teh base class, but only implement them in the child classes.

The form is something like this:

*** Source Snippet Removed ***


You could then do something like this:

*** Source Snippet Removed ***

The correct child version of the virtual function should be executed in each case.

If you want to know what type of object was called, include a virtual function that returns the type of object that it represents, such as:

*** Source Snippet Removed ***

However, there is another question that I would like to ask: Are you sure that you want to create separate classes for different types of inventory item? I daresay that it can be very useful (I can see it being used for such items as Ultima VIII's keyring item, for instance, which acted in a different way to other inventory items), but is it really called for in your case?

What about storing the object's information, and perhaps scripts for its interactions with the world, in a single object. Include a name variable with which to identify the object, for example, and perhaps which actions it can be used with.

A very simple version might have something like this:

*** Source Snippet Removed ***

In this case, I presume that you would somewhere have enumerations that specify the actions and scripts that are allowed. When the player attempts to do something with the item (such as hitting someone with it), simply check the requested action against those specified in the valid_actions vector and, if it is there, perform it with that item, and otherwise tell the player that they are a silly player and that, for instance, they are not allowed to hit people with bottles of expensive magical elixirs.

This system could of course also be extended to allow parameters for the scripts, to, for example, specify how much health to deduct from the player.

Note that in the cases of such things as axes and swords, you might want to make the actual wielded weapons different to inventory weapons, or have their script simply set the "current weapon" statistics appropriately, depending on how you are handling such things, instead of creating separate classes to allow for different abilities.

Hmmm...very interesting. So I can completely understand a derived class for each type of weapon from a base Weapon class, which would allow for weapon-specific modifiers to take place within each derived class and allow for various weapons to be created with different damages and speeds. Makes perfect sense to me, sounds like the right way to do it.

But, I really like your suggestion, though I'm unsure on the benefits of using a system such as yours. It seems like you would be doing a lot of typing when creating an object of InventoryItem and it would be a bit confusing later on of what you're dealing with. So if you could please explains this method a bit more that'd be sweet hah, thank you

Quote:Originally posted by Shakedown
But, I really like your suggestion, though I'm unsure on the benefits of using a system such as yours. It seems like you would be doing a lot of typing when creating an object of InventoryItem and it would be a bit confusing later on of what you're dealing with. So if you could please explains this method a bit more that'd be sweet hah, thank you

Well, yes, it probably would incur more typing, but it has the advantage that, as long as you can implement your desired object with the script commands that you have defined as being available, you can specify new items in external files without having to recompile your code, which can speed things up and increase convenience of development.

Just change your script, re-run your program, and your new behaviour should be present in your game, without recompilation. As well as this, as long as your scripting system doesn't have loopholes, your scripts shouldn't bring down your program, let alone produce compilation errors to chase down (since you shouldn't have to recompile) on top of any corrections that you might want to make to the behaviour that you just created.

Other than that, is there any particular part of the system that you'd like explained further?

Wikipedia has a general article on scripting languages; what I'm describing here is probably what they describe as "application-specific languages", although they have only a brief section on it, I'm afraid.

Quote:Originally posted by Noobis
I created my weapons through base class ITEM- so that I could use them and class them as Items, but I thought I could make a VECTOR within my character class.

vector<Item> inventory;

but I can't.

Ah, you're right, of course - I made a mistake in my original post, I think, for which I apologise. Instead of creating a vector of Items, create a vector of pointers to Items, like so:



Then create pointers to your individual subclasses, and store those, like so:



As to scripts, a game script needn't be as set in stone as a movie script - they're related, but a game script can include choices.

Essentially in this case the scripts would each be relatively small, unconnected sets of commands, such as the command to decrease the player's health, rather than a single monolithic and unchanging description of each moment in the game, as with a movie script. The commands, please note, may include randomness, and may be selected from randomly or assigned randomly. Furthermore, they may be "written" as the game progresses.

In the metaphor of a movie, instead of a single document by which the actors are controlled, think of lots of little documents that describe how a given actor should act under certain circumstances, and which may only be written as the movie is being filmed, and, should the movie be re-filmed, which may change drastically as they are re-written.

Thus, let's say that you want to create an Item which is an axe that the player can wield. Let us further say that you want the axe to do a random amount of damage between 1.0 and 5.0, and, with a certain low probability, may have a randomly selected magical ability. I will presume for now that you have a function that returns a random value between 0.0 and 1.0 called getRandom().

If we use scripts, we could use a script vector to store the scripts to execute, and a parameters vector to provide them with information that they might want, such as amount of damage to inflict, amount of health to restore, number of monsters to summon, etc. How you relate those is up to you - you could even keep them all in one vector if you wanted to.

Thus we might have something like this:



Note that these are extremely simple, one-command scripts. A more complex one could include multiple commands.

Just a note on virtual function usage: don't forget to make the destructor of the base class virtual as well. Otherwise, when you call delete on a base class pointer that points to an instance of a derived class, only the base class destructor is called, leaving you with a half-destructed object somewhere in memory.