Skip to main content
gamedev.net
🔒 Locked

External Objects

Started by ghostfacelz 6 replies 1k views
Original Post
ghostfacelz
ghostfacelz
Hi, Just needed some info / advice / suggestions on the follwing... I have heard that keeping most values externally (as in a file that gets read in) is the best way to go as you dont have to recompile when tweaking settings. Along the same lines, I was thinking of expanding on this thought and make actual objects in text files. Here is an example: (quick and dirty) class weapon { public: int range; int damage; } class rifle::weapon { string name; range = 15; damage = 20; } I know syntax is way off, but given as an example. :) in any case, so say I have 20 different weapons, normally I would create 20 different classes. This made me think, what if I want 50 different weapons, or add new weapons in the future? So, I started to think is there a way for the game to read in a file and make these classes while the file is not EOF? so as an example, in a text file i have: "Rifle" 15 20 "Rocket Launcher" 8 50 would it be possible to iterate on this file to make the rifle object and a rocket launcher object and whatever else is there? in addition, if i have 50 soldiers, 20 have rifles and the rest have various others... how would they use these objects? Simply solved in classes by making the object for each soldier. EX: Rifle rifle1; rifle1.assign (soldier1); I know I am asking a lot, but any advice anyone can give would be greatly appreciated. (and credits will be given :) ) I have heard scripting languages (LUA / GameMonkey) could help. Is this a viable option? Thanks in advance. =Ghost=>
Spoonbender
Spoonbender
You can't define new classes at runtime in C++. It's possible in C# or other languages with reflection, but is probably still overkill in your case.

But perhaps the real question is, why do they have to be different classes in the first place? There's no different functionality, from what you've shown, just variables that are initialized differently.

So why not just use the weapon class, and create a new instance of that for each type of weapon you read from the file?
ghostfacelz
ghostfacelz
I could do that, but wouldnt that cause more of a headache later on? If at a later point in the game, I have another soldier that gets a second (lets say rifle in this case), I would have to parse through that file to find the correct object to create.

I may be overthinking this whole thing, but in a nutshell, I am trying to implement a way to mod the game.
A way to create x number of item types defined outside of the game. This x number of item types can have y number of instances.
Sneftel
Sneftel
You've got two separate issues there: The disk-based representation of the object, and the creation process.

First of all, let me strongly advise you against rolling your own file format. Either go with XML with something like TinyXML, or JSON if that's your preference, or even something like Lua. Making your own file format and parser (particularly without the aid of a parser generator) inevitably comes down to a compromise between terrible syntax and arduous parsing code.

As for your second issue, there's nothing that says that the data can only exist on disk or in the hands of your soldier guy. In your case, check out the Prototype pattern (EDIT: found a better link).
ghostfacelz
ghostfacelz
Thanks for the advice.
I had no intention of creating my own parser. :)
I was actually looking into using LUA or GameMonkey.

As for the Prototype/cloning stuff, its very interesting. It looks like it could be exactly what I am looking for. However, it needs some research. This abstract stuff really makes my head hurt :)
Thanks alot for the link(s).
Sneftel
Sneftel
I actually can't find a good link that explains the breathtakingly simple concept behind the Prototype pattern. Here it is.

Instead of remembering how to create a Rifle, just keep a Rifle around, and copy it whenever you need a new one.
ghostfacelz
ghostfacelz
Haha.. the concept makes total sense.
I understand what it is that it's trying to do. (and it sounds like exactly what I need)
"
We must understand that the Clone() method does a Shallow copy not Deep copy. So it just returns a reference to the original copy unlike in Deep copy where a duplicate instance is created. Any changes made to the clone will be reflected in the original copy and vice versa. We can implement Deep copy by using ISerializable interface.
"

It's the implementation that will require some research.
Zipster
Zipster
If you're going to use the prototype pattern, then I highly recommend you also make use of the flyweight pattern. It basically allows you to put all the common information about an object type in one place without having to duplicate it for each instance. For example, each bad guy of a certain type will probably start out with the same max health, so why copy that data per instance? Just have a single instance of a bad guy type that stores that data once.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.