2
\$\begingroup\$

I'm pondering about the best way to represent objects that can be picked up in my 2D engine.

I have an Actor class which is the base for all objects that can be spawned into the game. This class offers a location and some other information needed by all actors.

Now, let's take an Apple for example. It's derived from Actor and carries with it all the information needed to be in the game-world. But when I pick this item up and put it inside an inventory, I don't need all that Actor stuff. So I was pondering. Does it make sense to maybe have an AppleActor class instead that derives from Actor, and inside it have an Apple class derived from something like InventoryItem?

When I pick up an Actor, I would take the InventoryItem out of it, store it in my inventory and destroy the Actor. Then, when I drop the InventoryItem, I would first create the corresponding Actor for it, put the InventoryItem inside it and spawn that Actor in the world.

Does this make sense at all? Any feedback or advice from more experienced people here is welcome.

\$\endgroup\$
1
\$\begingroup\$

I would keep the underlying data model for my inventory separate from the visual representation (MVC basically) for exactly the reasons you bring up. I'd have an AppleActor while the object is actually spawned out in the world, but once I pick it up it's just an ID (probably a key in a dictionary that associates ID with amount) in the InventoryModel.

\$\endgroup\$
2
  • \$\begingroup\$ And how would you handle Actor creation? Should the InventoryItem offer an ActorFactory method? \$\endgroup\$ Jul 31 '17 at 18:12
  • \$\begingroup\$ I'd probably do ActorFactory as a separate class that just takes in an item ID, rather than something owned by InventoryItem, but basically yes. \$\endgroup\$
    – jhocking
    Jul 31 '17 at 18:14
1
\$\begingroup\$

I wouldn't make Apple an Actor. Make Apple an Item and allow Actors to hold references to them via a backpack, which could just be a List or array of Item, or a hand which is a Item ref. Now your Actor can just walk around picking up and dropping Items, as in the real world.

Related: You'll find dynamic languages tend to have a top-level object type. You'll notice these usually don't have much in them, because when that object can represent just about anything in its role as a base class, it's very difficult to get specific about it without forcing derived objects to carry around unnecessary methods and members. The same is true in your case; while it may seem attractive to have some sort of generic, top-level GameObject class (in your case, Actor), it's not always the right way to go about things. You've said you need e.g. position... so, OK then.

I would keep Actor for actual walking, talking things and use a different name for your top level... if you decide to have a top level at all.

The way to decide that is to ask, "In what ways are these objects processed similarly?" If they are never processed or held in the same ways, then don't bother having them derive from the same base class. If they are processed in some similar yet abstract way, then do give them a base.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.