I use Farmville as a structural example, simply because it's widely known, but the game that I'm working on isn't that similar. I've got the isometric map working, and the part that I'm having problems with is the part that I thought would be easy.
Basically, I'm making a game where a character can walk around a map and collect items that they find laying around. These items would then be added to the player's inventory. (To compare to FarmVille again, consider all the objects a player has in their inventory) Should be simple enough. However, since each item has particular statistics (ie. quality), I was trying to store these items in an array of objects (so each object can hold it's own qualities) as opposed to just an array of unique identifiers for, say, an item table in the database.
Just for syntax, I'm programming in Actionscript 3.0 (Flash CS5).
I may just have my scope messed up, but at this point I've looked at it so much, I'm not getting anywhere. How can I store items that the character picks up in an array, keeping all the additional values that each object contains?
If you can supply a coded example, that would be great, but if not I'm sure I can put it together.
Thanks in advance for any insight. I'm growing frustrated at the simple things stumping me. Hopefully I just need an outside brain to think about it. :)
"Farmville"-like Game Design
You can make a struct for objects containing all the data, (object type, quality, weight, value, etc.) and put those structs in an array.
Since the items you collect doesn't seem to have any bahavior of their own once you collected them you dont need them to be objects.
When an item is lying on the floor its an object since it has to hold it coordinates and draw itself (or be drawn), when you pick it up, you add and element to inventory array and destroy the object on the ground.
Since the items you collect doesn't seem to have any bahavior of their own once you collected them you dont need them to be objects.
When an item is lying on the floor its an object since it has to hold it coordinates and draw itself (or be drawn), when you pick it up, you add and element to inventory array and destroy the object on the ground.
Author
klefebz,
Thank you for your reply. The objects do it fact have behaviour methods that I didn't go into, however I may be able to work with that concept you suggested and expand it.
For example, one method that an object could have would be a Deconstruct method, which essentially pulls the items apart. If, let's say, you had a bicycle object, you could choose to 'Deconstruct' it and create several other items instead (a seat object, 2 pedal objects, etc.). My idea was going to be to open up an inventory screen, then when you click on the individual items, depending on what methods were present for that object, a dynamic list of options would be created.
Thanks for your input, though. I'm going to work with that idea and see where it gets me. Grats!
Thank you for your reply. The objects do it fact have behaviour methods that I didn't go into, however I may be able to work with that concept you suggested and expand it.
For example, one method that an object could have would be a Deconstruct method, which essentially pulls the items apart. If, let's say, you had a bicycle object, you could choose to 'Deconstruct' it and create several other items instead (a seat object, 2 pedal objects, etc.). My idea was going to be to open up an inventory screen, then when you click on the individual items, depending on what methods were present for that object, a dynamic list of options would be created.
Thanks for your input, though. I'm going to work with that idea and see where it gets me. Grats!
Pardon me if my response is somewhat idiotic, I'm new here.
If every item is going to have a unique set of methods, but still have some basic characteristics in common (they all have names, they all have a component list, they all have a deconstruct method) then it seems to me that your best bet would be to create an Item parent class and then individual child classes for each item type. Of course, this could become an issue depending on the diversity of your item catalogue. To handle a wider selection of items, I would probably break them down into a pile of different items with the same functionality, just different content. Something along the lines of "vehicle" instead of "bike"- all vehicles (like cars, bikes, unicycles, segways) have some basic functionality in common; you ride them, they take you places, they have wheels, they have a steering item, etc. By breaking up your items into larger type categories, you can drastically reduce the number of classes you need to write, and reduce the OOP overhead.
If every item is going to have a unique set of methods, but still have some basic characteristics in common (they all have names, they all have a component list, they all have a deconstruct method) then it seems to me that your best bet would be to create an Item parent class and then individual child classes for each item type. Of course, this could become an issue depending on the diversity of your item catalogue. To handle a wider selection of items, I would probably break them down into a pile of different items with the same functionality, just different content. Something along the lines of "vehicle" instead of "bike"- all vehicles (like cars, bikes, unicycles, segways) have some basic functionality in common; you ride them, they take you places, they have wheels, they have a steering item, etc. By breaking up your items into larger type categories, you can drastically reduce the number of classes you need to write, and reduce the OOP overhead.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
