SCI1.1 Room Interactions

So you have your room drawn and you have some Prop thrown in now it is time to give it some life. When the player attempts to interact with different areas or views in your room, they are more than likely expecting something to happen... at the very least a print statement or two. This chapter will show you how to make simple responses for the users click. By simple I mean just returning a message to the player. The next chapter will explain how to make more complex interactions, ones that actually cause something to happen in the game. But for now, lets at least get them some descriptions of what it is they are trying to look at.

View Interaction Simple Response

Lets begin with interacting with a view. When we created our view, one of the properties of the instance was noun and if you remember correctly, we had to go into the messages resource for the room and add N_BROKENMUG to the noun list. Hopefully this looks familiar.

Code: [Select]
(instance brokenMug of Prop
  (properties view 251
                    loop 2
                    cel 0
                    x 114
                    y 91
                    noun N_BROKENMUG
  )
)

Well, now it is simply a matter of adding more messages to the message resource. Depending on how dedicated you are, you could realistically add in a message for every possible Verb. For now though, let's just add a new one for the Noun BROKENMUG and the DO Verb. The rest of the options, we will leave as the default. Once we enter a message that would be appropriate for picking up a broken mug, something like "No way I'm putting that in my pocket, there are way too many sharp edges." and hit Commit, we are ready to save the resource and run the game. Once you are in the room, select the Do cursor and attempt to pick up the broken mug to see your newly added message.

Control Color Interaction Simple Response

Well there are going to be times when the user wants to click on something that is drawn as part of the background. For instance maybe a set of stairs. For this scenario, we are going to need to fill in the stairway area with a control color. I usually start with Navy and work my way up the scale depending on how many feature areas I need. Once the area has been filled in, it is time to go to the script for the room. Just like when adding views to a room, when we add a feature we are going to need to create an instance.

Code: [Select]
(instance theStairs of Feature
    (properties
        x 160
        y 180
        noun N_STAIRS
        onMeCheck ctlNAVY
    )
)

Just like with the views, Features have a noun property. Also, just like with the views, the message to be displayed will be defined in the message resource by the Verb Noun combination. The key here though, is the onMeCheck property. The onMeCheck is where the control color that signifies the particular instance is defined. One more thing to note, you'll notice that there is an x an y property defined. These values are used to determine if the ego is facing them or not. If he is not, the ego will turn to look at the area before triggering the response. Now before we go on, just like with views, in order to add the instance to the game, it will need to be inited. If you haven't read through it yet, might I suggest the chapter on adding views to a room chapter as it will go into more detail about where this next snippet of code should go. In the rooms init method of the public instance, we add in the code to init our feature.

Code: [Select]
(theStairs init: setOnMeCheck: 1 ctlNAVY)

You'll notice that the setOnMeCheck property is again defined here. I am not really sure why, but it doesn't work if you don't so just keep in mind to set it in both the instance and the init statement and you'll be fine. So now, once again open your message resource and add in a response for the verbs you would like a response for, such as N_STAIRS V_LOOK responds with "The stairs are often used for traveling up and down".

Polygon Interaction Simple Response

Unfortunately, there are only so many control colors that can be used before you run out. There may come a time when you want to also be able to just click on a defined polygon. Again we will be adding a feature in order to accomplish this. This time though, in the instance of the feature we will also be adding an init method so that the polygon area can be defined.

Code: [Select]

(instance ocean of Feature
(properties
y 190
noun N_OCEAN
)

(method (init)
(= theOnMeCheck
((Polygon new:)
type: PBarredAccess
init: 0 93 320 93 320 190 0 190
yourself:
)
)
(= onMeCheck theOnMeCheck)
(super init: &rest)
)
)

Now because we are using a couple of variable names here to handle the polygon creation, we are also going to need to add the variable up at the top of the script and define it as a local variable. SCI does not let you make up new variable names on the fly, they have to be defined but don't worry, that is easy enough. Just following all of the use statements include the local variable declaration.

Code: [Select]
(local
    theOnMeCheck
)

And of course, once again we will need to init the instance in order for it to be included in the game. So just like up above, in the section where everything is inited add in

Code: [Select]
(ocean init:)

Now all that is left to do is add the appropriate messages to this rooms message resource for the noun that we defined in the instance. So something along the lines of N_OCEAN V_LOOK responds with "The ocean waves look peaceful, but who knows what dangers lie below the surface.", Commit, save and run your game to see it in action.

Ok, so I am sure there are still another dozen or so ways to trigger off a print message when the player clicks on something, hopefully for now, this will be more than enough to get you started. The next chapter will cover how to make these simple interactions far more complex. The good news though, is that they complexity comes from adding in methods to the instances and can be applied to these examples in exactly the same way.