Object Making Basics

The simplest type of object is the Scenery object. This is purely an image which will overlay the background and is usually used to give the impression of depth within the game area - for example, a stone pillar that objects will pass behind. These objects have no physical presence within the world apart from an imageplane which will state at what screen depth it should be displayed. Scenery objects have no unique classifier, they all belong to family 1.

A SimpleObject is by far the most common type of entity within the world and it is this type that most COB builders will create. A SimpleObject is made up of one part and has the possibility to be activated, carried, respond to gravity and/or boundaries.

A CompoundObject can be made up of many parts and has the possibility to be activated and respond to gravity and/or boundaries. CompoundObjects can not be carried though. CompoundObjects are also able to have a cabin which is an area for carrying creatures or other objects placed within it. CompoundObjects can also have different activation spots defined, which means that you can have 2 or more seperate regions on it - each one producing a different effect when clicked on.

The most important part of creating an object is assigning it a classifier. This classifier will uniquely identify the type of object and allows it to own event scripts that will dictate it's behaviour and response to the world around it and/or other entities. The classifier for an object gives it a family, genus and species.

Family is the broad category that an object belongs to - for COB making the family groups of interest are family 1 - Scenery objects, family 2 - SimpleObjects and family 3 - CompoundObjects. Chose the family most appropriate to the functionality you want the object to have, for example - an object designed to be picked up and eaten by a creature should belong to family 2.

Genus further defines the object as belonging to a certain subgroup within a species - have a look at the classifier reference for a list of the genus's available and what they represent. For example, our object that we want to be eaten is a bar of chocolate and so we can use genus 6 - called 'processed food' - as opposed to 'animal', 'call button', 'fruit' or any of the other genus's available within the family 2 group.

Species is the last step in classification and is where a type of object can then be uniquely defined. For example, family 2 genus 6 consists of some elements already ... cheese and honey and walking pie. We can then make a new species called 'chocolate' and use an available slot to number it. This results in our new agent having a classifier of family 2 genus 6 species 4 (or just 2 6 4 as it may sometimes be represented).

This classifier is important because when you create an event script for the object, for example a script that injects the creature with some form of nutrition whenever the chocolate is eaten, you have to mark the script as belonging to a particular type of object. The way the script is marked is using the classifier (and an event number, but we'll come to that). This means that the script for a piece of chocolate, marked as belonging to 2 6 4, will operate on *any* objects marked as 2 6 4. This is why the classifier must be chosen carefully, you must make sure you are using a classifier that no-one else is using - if you are then the objects that try to use the event scripts can end up getting confused. For example, lets say I make a chocolate item that uses 2 6 4 as it's classifier and give it an eat script - I put it into my world and everything works fine. Then, suppose someone else makes an object, lets say a cheeseburger, but they also use the classifier 2 6 4 and give it an eat script too. If they don't have my chocolate in their world then everything will work fine for them, but if I was to then add their cheeseburger to my world I would actually end up overwriting my chocolate eat scripts with their cheeseburger eat scripts. At best this will just mean that you have an object that looks like chocolate but when eaten gives a cheeseburger result, at worst it will crash your system as the cheeseburger script tries to make the chocolate go into a pose or do things it wasn't intended to!

For this reason the CDN will be keeping a register of classifier numbers, and as long as you register your classifier with us then no other CDN member will produce an official object that will clash with yours.

Pickup - an event that happens when an object is picked up by the hand and/or any creature.

Drop - an event that happens when an object is picked up by the hand and/or any creature.

Activate 1 - an event that happens when an object is clicked on by the hand and/or any creature.

In order to allow any of these events to happen we need to create the object and give them some properties that define their attributes - the key commands for this are attr and bhvr. If you look at the values that attr can take in the CAOS Language Guide you will see that the important ones for this tutorial are the attributes carryable (a creature can pick the object up), mousable (the mouse can pick up the object) and activateable (the mouse can give an activate message to the object). The way that you specify the attributes you want is by choosing the relavent ones and adding up the number value for them, in this case we end up with the number 7 (1+2+4). For this tutorial we also want the object to fall from the hand when released (suffers gravity attr +128) and stop when it hits the floor (has boundaries attr +64) - which results in a value for attr of 199. The second part of specifying how an object behaves is with bhvr - which specifically details the kind of reactions a click produces and what a creature can do to it. Both attr and bhvr are detailed more in another tutorial, for now just trust me and we'll use bhvr 1 1 for our object.

Ok, lets start simple and create a simple object, we'll use the graphic for Pitz the dog, - the chunk below will do so. If you are unsure as to the commands being used you should check the CAOS Language Guide.

This will create our object, give it a classifier of 2 1 10000 and set it up with the attributes and behaviour we want. The last 2 lines place it into the world and move the camera to look at it.

If you inject this into the world you will notice that it just floats above the ground, which may be a surprise considering that the object should respond to gravity. The reason for this is that all objects that respond to gravity need to be put onto the gravity list before it will take effect. One way to do this is to pick up pitz and drop it - the act of dropping it triggers the gravity effect. If you want to have it affected from the moment it enters the world you should change the chunk so that it now reads:

You should find that the object we have created can be picked up and when you click on it the hand performs it's activation pose (the finger presses the object).

So now we are ready to give it some events - lets start with a pickup event (this will be run every time the object is picked up).

We'll do something simple and just change the pose, if you have a sprite tool you can look at the sprite file pitz.s16 and choose your own pose - or just copy this example which will chose a suitably different pose.

This chunk will be stored in the scriptorium (a place in the world where all event scripts are stored) and the header 2 1 10000 4 marks it as belong to any object with the classifier 2 1 10000 but also that this is the event for pickup. A list of all event numbers can be found in the CAOS Language Guide.

Inject this and pickup Pitz - he should change pose. Drop him again and he'll stay in this new pose. If we want him to go back to the way he did look we need to define a new script - and this will be for the drop event.

Inject this and pick up and drop pitz a few times.

So that has dealt with what the pickup and drop scripts are about and when they will trigger. The next stage is adding some activation to the process. We'll keep it simple again and just alter the pose once more, this time to something more appropriate.

Try adding the chunk:

Don't worry about the setv actv 0 at the moment - that will be explained in more detail in a different tutorial. Just be content with the fact that it will allow the object to be activated more than once.

Inject this and click on pitz - he should roll onto his back.

So now we have an object that changes pose whenever it's picked up, dropped or clicked on. Not very exiting but it's a start!

Getting things into the game is all when and good - but if you can't remove it you're going to run out of space at some point. Removing objects is something you'll be asked to do a lot throughout these tutorials and there are a few ways to achieve this. If you want to remove every occurence of a particular object (e.g. all balls) you would use the following fragment - replacing the spaces with the actual classifier of the object you want to remove.

This fragment can then be injected into the game in it's own right - open a new COS window for it and inject it. The required objects will then be removed from the game.

To remove a single object you should be in cheat mode and SHIFT-CLICK on the required object - you can then hit the delete button once this object is attached to the mouse. Be careful with this method as it is possible to pick up any in-game object - including passing weather clouds, scenery or creatures.

Removing the scripts for an object is a method of clearing up behind you - making sure you leave no unwanted event scripts in your world. The best way to remove a script is with the CAOS Tool which has a scriptorium browser ability, and from here you can check which scripts exist and delete them as needed.

The command for removing a particular script is the following:

where you fill in the slots specifying the required event.

Why would you want to remove scripts? There is a limited amount that can be stored within the world and if you never removed old ones you would soon run out of space and be forced to clear some out before adding a new object, so if you get into the habit of removing them as they become obsolete you will always have a relatively tidy scriptorium. The more fundamental reason for removing scripts is that it is very easy to get yourself confused because of an old script you forgot about. For example, suppose you created a bird that used a collision script to change a variable to indicate it had landed. After playing around with this object for a while you decide that in fact you can acheive the same thing using a different method and so now create a bird without a collision script. A problem will arise if you haven't actually removed the script and it is still in the scriptorium. Just because you create an object and inject it with scripts it is not restricted to the ones you inject with it - if any stored scripts match it's classifier then it will use those when the situation is right (in our example, whenever a collision occurs).