the inventory class will be implemented as a singleton.

Its basic functionality will be wrapping a std container, probably a map.

supported actions are ‘add’, ‘remove’, ‘replace’, ‘contains’ – all of which will be implemented as standard actions, usable via the node system.

In order to make the inventory system available similar to the way classic point&click adventures worked, a new trigger will be added to the node system.

The trigger’s responsibility will be to report to any connected component which item the user tried to use with the trigger’s parent object.

List of new actions/triggers:

• ‘used with’ trigger: outputs the item ID of the used inventory item
• ‘add to inventory’ action: removes an object from the scene and adds it to the inventory. Alternatively, if the action is not connected to any object, it can spawn a new item via its ID and directly add it to the inventory.
• ‘remove from inventory’ action: removes an action from the inventory and displays it in the scene. Alternatively, this action can remove & delete an object without it being transferred back to the scene.
• ‘replace’ action: replaces an item that already is contained in the inventory with a different object (see ‘add to inventory’). The difference her is that the ‘replace’ action won’t change the internal order of the inventory.
• ‘contains’ action: will return true or false, depending on whether or not a certain item id exists within the inventory.

Using these actions and the new trigger, more or less complex systems can be built where users can pick up items, combine them, use them with scene items, place them back on the floor, etc.

inventory system – draft

every single object that has been placed in the world has the potential of being picked up and added to the player’s inventory.

A new action would have to take care of hiding the object and spawning a new inventory item (perhaps a new subclass of cp407object).

The visual representation of the inventory could at first be a simple list, displaying all the items a player has in his/her possession.

a next step would be to replace the list by thumbnails (RT previews of each object – in which case subclassing CP407Object would make sense).

Objects in the inventory can be placed on the floor via drag&drop

new object properties / dynamics

weight: a thought – each object consists of a certain material that has a specific weight. The object weight is calculated by multiplying the specific weight with the volume of its bounding box. That way, objects of the same type but with a larger bounding box get heavier, increasing the chance for players not being able to pick them up. It wouldn’t make much sense if players could pick up cars or trees.

another thought: aging items: consider a seed item a player has in his/her inventory. As long as it’s in there, nothing happens to it. If however, the player puts the seed onto (or into) the ground, it starts growing, building a tree, bush, flower, etc. with time.

This principle could be applied to all kinds of objects, such as food items going bad, items that are seasonal or dependant on a certain environment (ice cubes – as soon as they are picked up, they start melting, gradually turning into a puddle of water)

In order to achieve that, each object has a birth timestamp. Whenever the age is queried, that timestamp is used to compute the object’s age.

Certain objects would need an ‘update’ callback that updates their age without it being queried.

example:

class CAgingItem 
{
  void UpdateAge()
  {
        m_iAge = CurrentTime() - m_iBirthTime;
  }
}

The ‘UpdateAge’-Function gets called periodically (1/s?).

in order to use the new nodes to connect path items with each other, the items need a set of new functions:

• createNode – to create a new node (the item has to store it, analog to the config window)
• ‘callback’-functions that get notified whenever a connection to a certain input/output connector is made

additionally, nodes need to be able to display certain UI elements within.

Continue reading →

a new node system will make scripting easier.

Nodes can be of type action, trigger or object and have different in- and output connectors.

• object nodes show their connections to their triggers
• triggers and actions show connections to their actions
• property window shows up upon double clicking a node (same window as before)

a connecting line between two connectors only visualizes that action A has a link to action B. How that link works is up to the actions in question. One action might modify another action’s properties directly (‘push-mode’) while another action reads a property of a connected action (‘pull-mode’). Both cases would simply display a line or curve between the two connectors.

a first attempt at rendering nodes inside a clipped area:

along with this change, the base action might be expanded:

each action might get the ability to trigger a remote action, just like the ‘execute’-action did before.

This works exactly like a follow-up action, except that the executed action can be a remote action and doesn’t have to be an immediate child.

Continue reading →