Inventory object discussion

This forum is currently in read-only mode.
0 favourites
From the Asset Store
This is a single chapter from the "Construct Starter Kit Collection". It is the Student Workbook for its Workshop.
  • Some of us have been discussing this on the chat; how exactly do you think an inventory object should work?

    My idea is that you'd place and drag an inventory in the layout editor, and have properties such as rows, items per row, background texture, etc.

    Then you'd have actions like:

    • Add item
      • Name
      • Sprite object
    • Remove item
    • Set item attribute
    • Save
    • Load

    And some configurable drawing options.

    Essentially the object would set up and draw your inventory, with your item sprites, and handle drag/dropping and clicking notifications.

    Any thoughts on this before I begin..?

  • My idea is to offload as much as possible onto other objects. For example, use an object to define a grid. Imagine that your object would only handle grids with square cells, and someone needs a hex-based grid. With grid defined in another object adapting it would be as simple as replacing the grid object with another one, rather than throwing the whole inventory object away and implementing stuff from scratch.

    My main idea is that small changes in design should require small changes in code. A (relatively) small change from square grid to a hex grid shouldn't render your object unfit for the task.

  • So basically, an inventory object, as well as a behavior.

  • It sounds brilliant, but to use it I would need to have it work with custom systems.

    In the game I'm working on, I have it like an adventure game, where you open the inventory, click on an item to have it disappear from the inventory and follow the mouse, then I can close the inventory and then click on a sprite to use the item on it. Currently I have a sprite that follows the mouse around and has all of the item animations, and automatically sets itself to what the mouse is carrying.

    If it was possible to get values and had enough control options, then it sounds fantastic!

  • I agree with Shviller, that is why I posted a feature request for Grid Object. I had inventory in mind as well as customizable tile maps or even compound sprites (containing different minor sprites such as body, clothing that you can change/recolor and eyes that you can change color of).

    As for inventory, it has to have the following features:

    • limited or unlimited (numbered slots to unlimited slots)
    • stacking (multiple items of the same type in the same slot) - option (different for say armor, which shouldn't be stackable, and ammunition, which should stack).
    • Put into inventory (at specific slot, at first free slot if there is no stackable of the type already)
    • Get from inventory (by slot or type) - substract/destroy or do not destroy (do not destroy is very useful for toolbars)
    • sorting (based on type, stacked amount, OID, expression etc.)
    • move between slots (swap, stack or split stackables...)
    • not necessary - varying item sizes (big armor would take more slots, etc., however that is merely a display thing; the space would be defined by size of grid and 3x4 object would occupy that much in 10x10 inventory space).

    Leave the way of putting/getting to other behaviors (drag/drop, mouse click etc.) via events.

  • [quote:wymuetwd]- stacking (multiple items of the same type in the same slot)

    Not sure if that's a good idea, you could have a thousand sprites all in one spot.

    Perhaps an automatic counter that would place text where you want it when you have multiple identical items?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Er, yeah, that is what I meant, it'd have one sprite, however it would store the amount of instances stored in the inventory slot. Sorry I was not clearer

    So, for stacking items, only one instance would be needed, destroy and spawn instances as needed... ammunition, potions etc.

  • Yeah, stacking as in multiple instances per slot is rather important.

    Okay, I think I'm gonna begin..

  • <img src="http://img10.imageshack.us/img10/8940/inventory.png">

    OK, thoughts on this so far?

    Should I add a grid feature?

  • I would like simple explanation in the upper tab in for the event wizard , for everything selectable.

    Won't it be simple to integrate ? All text could be taken from the wiki definitions or so.

  • That looks cool already!

    So, about the behavior thingy - I only see 2 ways of how people could use the interface. With a controller / keyboard, so that the controls are sorta like in every Zelda title or through the mouse, so it's probably a bit Diablo'ish. So, it'd have to be linked to the input system. Like newt already said, it'd make sense to have it in there as an object and as a behavior at once.

    One idea is that we could set it to 'Grid' (typical keyboard / controller way like Zelda), 'Mouse' (like Diablo) or 'Combined' (so that both works and so that we can set up the controls accordingly).

    I think it'd be the smartest thing to probably directly set up the appropriate settings the moment you use the inventory object in your scene. So, say for a Zelda-like inventory, if I pop up my inventory, I'd immediately expect that I could move along the grid using the same inputs that I'd use for moving my player around, right? So, Move Up / Down / Left / Right should directly be used without us having to setup control schemes. Otherwise, we'd have to create a whole Inventory Event Sheet with inputs like these:

    if player presses 'Move up" - Inventory: Move up

    If player presses 'Move right" - Inventroy: Move right

    etc

    Which still could be nice for whatever as an option. So we could override the defaults, but I think 90% of the users would settle for a Zelda or Diablo like Control Scheme. If I look at all the Inventory systems out there, they're all either like Zelda / Final Fantasy / Diablo, really.

    Also, if we pop up the inventory, as long as the inventory is active, it'd probably be smart to give the user the option to freeze any inputs on other layouts. Imagine a Zelda game where you're running around on a cliff and quickly need to switch to an item, you pop up the inventory, press 'Move Right' 3 times and boom, you fall down the cliff, but at least you're at the right item spot in your inventory. So, if Inventory is active: Ignore all user input on all other layouts.

    Same thing with the mouse. You'd want to have stuff in there like: If mouse hovers over an item spot, do whatever. Like, change the backdrop, add an effect to the item spot or something, so that you'd always get an input what you're currently hovering over. And the option for: if inventory is active: Ignore Mouse input on all other layouts.

    Then we'd still have to setup how we'd control the inventory, cause that'd probably be a little different for everybody:

    If player presses 'Tab' - Inventory: Show Inventory

    If inventory is active + If player presses 'Tab' - Inventory: Hide Inventory

    • easy.

    And now it's about interacting with the inventory:

    If player presses 'Action' + Inventory is active - Inventory: Use item

    For keyboard only. Or:

    If player presses 'Action' OR if player right clicks + Inventory is active - Inventory: Use item.

    For 'Combined'.

    Then we'd still have to find out what kinda options we'd need.

    Use Item? Drop Item? Equip Item? etc.

    Now that I'm thinking about it, it'd also make a LOT of sense to have a 'Menu' Object too, right?

  • OK, thoughts on this so far?

    Should I add a grid feature?

    My first thought: awesome.

    second thought: border and fill color for the stack counter background square.

  • They're both there, just hidden in the properties (I run lowish res) .

  • I would like simple explanation in the upper tab in for the event wizard , for everything selectable.

    Won't it be simple to integrate ? All text could be taken from the wiki definitions or so.

    Hm?

  • thomasmahler hit on something, an automatic pause would be nice as an option. There might be times when you would want some other activity to stop when the grid is on screen.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)