Design Item behind Item Design

Discussion in 'Game Design, Development And Publishing' started by samspade, Apr 10, 2019.

  1. samspade

    samspade Member

    Joined:
    Feb 26, 2017
    Posts:
    1,931
    Basic description - I'm working on what is effectively a point and click project right now. I'm looking for ideas about structuring a piece of code for items which you can pick up behind other items. Not looking for code just the structure you might use. Here are some examples

    • You walk up to a book shelf, click on some books to 'move the books' and behind the books there is an item which you can click on to pick up.
    • You look at a vent, and behind the vent you can see an item. You remove the vent and can then pick up the item.
    • You walk to a drawer and slide it open partially obscured is an item, you can click on it to pick it up.
    I think the above are the three primary scenarios but there might be more. The design difficulty comes mainly from how these things interact with each other.

    For example, in the first case, I could put the books on a layer in front of the item and make it so that you can't click on an item unless it is the 'topmost' item. So first click interacts with books, second click interacts with item. This would also work in the second case. However, it doesn't work in the third case unless the drawer is a multi-part sprite as for the item in the drawer to be partially obscured, it would have to be over a layer of the drawer and under another layer.

    Another example is I could make it so moving the books or opening the drawer 'spawns' in the the item. And closing despawns it. But then in the second example, the vent has to have separate art to 'show' the item behind it and not 'show' the item behind it.

    A third example would be to not actually have separate objects for this but have it be stages or states of the same object with different sprites and codes for each. This however could be complicated if there were multiple items or the 'hitbox' for the item was significantly different than the 'hitbox' for the object in front of the item as I would then have to allow for and define special regions for every instance of the object that I use.

    I could also just use all three depending upon which is easiest in each scenario.

    I'm wondering if other people have dealt with this and if so what they chose to do?
     
  2. Danei

    Danei Member

    Joined:
    Mar 23, 2018
    Posts:
    278
    I haven't personally done this, but it sounds to me like the 2nd option would be easiest to implement. It's true that the vent would in that case require an extra piece of art for a with-item state vs its no-item state, but since you're going to have art for the item anyway, that doesn't sound so bad. Depending on the type of art and the perspective you're using, it could be as simple as having a vent object draw the item's sprite first and then draw its own sprite on top, with the item visible through the transparent parts of the vent sprite. That would even allow you to have any arbitrary item or a random item in the vent.
     
  3. immortalx

    immortalx Member

    Joined:
    Sep 6, 2018
    Posts:
    296
    The first thing that comes to my mind is have these objects treated as pairs. Let's call them "container" and "item". Have the container objects be "special" compared to all other interactive objects, by sharing a common parent. This parent object could have an additional property "open", which will flip-flop with every mouse click.

    Like above, have the item objects have a common parent with a property "container", which will hold the instance of the container they belong to.
    When you test for mouse clicks on "item" instances, have them read the "open" property of their container, and determine if they can be acquired or not.

    I assume that you place the objects with the room editor, which means you either have to set each item instance's container in the instance creation code, or maybe in the create event of the item-parent, check for collision with the container-parent (they would be overlapping anyway) and set the ids of the container instances there.

    I don't know if all this sounds reasonable because I might be choosing wrong wording (not a native speaker here).

    EDIT: Maybe a visual representation could help.
    obj_covered_items_parent
    ----obj_key --> container = (an instance id of a obj_drawer, obj_vent or obj_books)
    ----obj_money --> container = (same as above)
    ----obj_wrench --> container = (same as above)

    obj_containers_parent
    ----obj_drawer --> open = false
    ----obj_vent --> open = false
    ----obj_books --> open = false
     
    Last edited: Apr 10, 2019
    samspade likes this.
  4. samspade

    samspade Member

    Joined:
    Feb 26, 2017
    Posts:
    1,931
    In thinking about this, there really isn't a reason to not do multiple versions and use the easiest one depending upon the situation. So I guess the answer for me will be all of the above and if anyone has even more ideas I'd be interested.
     
  5. NightFrost

    NightFrost Member

    Joined:
    Jun 24, 2016
    Posts:
    1,785
    I would use spawning method. A clickable target would be given knowledge that it is capable of spawning another item. When it has been successfully manipulated (details depend on how your game works) it would spawn a new clickable target somewhere into the room. The clickable would also know if it is see-through; if it is, it would draw the sprite of the covered item first, then itself on top. Or a partial draw, in case of a drawer with something sticking out of it a little.

    You could also use this arrangement to create switches that for example open a door elsewhere in the room.
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice