Differences

This shows you the differences between the selected revision and the current
version of the page.


wmebook:ch6 2008/01/10 12:00 wmebook:ch6 2008/01/10 12:04 current
Line 201: Line 201:
</code> </code>
-Not very logical game play, eh? But it shows the point. Sometimes it’s good to destroy item altogether for example if we want to combine two items to get one or if we use the item and don’t want player to have the possibility to reacquire it. For this we have in stock the DeleteItem method.+Not very logical game play, eh? But it shows the point. Sometimes it’s good to destroy item altogether for example if we want to combine two items to get one or if we use the item and don’t want player to have the possibility to reacquire it. For this we have in stock the **DeleteItem** method.
Before we look more into items handling, let’s look at the item in the inventory. We know, that in items.items there’s a script assigned to it. This is the file, which takes care of the item when it gets to the inventory. It’s not limited to a single scene as our previous script was and this way we should count with the fact that the player would try to use this item anywhere in the game. It would be really painful to create individual responses for each hotspot so basically we want to have unique responses for logical things and some generic “It doesn’t make any sense to use the book here.” for the rest of the hotspots. Before we look more into items handling, let’s look at the item in the inventory. We know, that in items.items there’s a script assigned to it. This is the file, which takes care of the item when it gets to the inventory. It’s not limited to a single scene as our previous script was and this way we should count with the fact that the player would try to use this item anywhere in the game. It would be really painful to create individual responses for each hotspot so basically we want to have unique responses for logical things and some generic “It doesn’t make any sense to use the book here.” for the rest of the hotspots.
Line 290: Line 290:
</code> </code>
-Now what we’ve done is that we’ve created another actor named Sally which uses the same graphics as a Molly, but it’s entirely different person. We have her reference stored in the global variable actor2 and we’ve placed her in our Room scene. Next thing we’re going to do is that we’re going to implement a neat character switching.+Now what we’ve done is that we’ve created another actor named Sally which uses the same graphics as a Molly, but it’s entirely different person. We have her reference stored in the global variable //actor2// and we’ve placed her in our Room scene. Next thing we’re going to do is that we’re going to implement a neat character switching.
If player clicks on Molly or Sally (without an inventory item selected) game gives control to the second actor. If player clicks on Molly or Sally (without an inventory item selected) game gives control to the second actor.
Line 322: Line 322:
</code> </code>
-Now we could use single file for this, but later on it pays off to have those separated when we want to perform different tasks with each actor.+Although we could use single file for this, later on it pays off to have those separated when we want to perform different tasks with each actor.
-Now run the game and note that we can now switch between actors by simple Left Click on them. +Now run the game and note that we can switch between actors by simple Left Click on them.
-So now having this done, we’ll return to our inventory and try some interactions. First what we need to do is open our trusty **game.script** and actually code in the generic logic of inventory item interaction. What we want to achieve is that whenever we left click with a selected item on a hotspot, we try to call the corresponding method named by an item name. So if we click with a book, we’d try to call a method “Book” of the target entity.+Having this done, we’ll return to our inventory and we try some interactions. First thing what we need to do is open our trusty **game.script** and actually code in the generic logic of inventory item interaction. What we want to achieve is that whenever we left click with a selected item on a hotspot, we try to call the corresponding method named by an item name. So if we click with a book, we’d try to call a method “Book” of the target entity.
This can be easily done by modifying the Left Click event to read: This can be easily done by modifying the Left Click event to read:
Line 382: Line 382:
Again it’s very simple logic. If actor variable containing the active actor is set to the clicked actor, we read the documentation or we say the other line. The event “book” is called because we modified the **game.script** to do this. Clear as mud? Again it’s very simple logic. If actor variable containing the active actor is set to the clicked actor, we read the documentation or we say the other line. The event “book” is called because we modified the **game.script** to do this. Clear as mud?
- 
Now we have one illogical thing. It doesn’t matter who picks up the book, both have the book in the inventory. This is the global inventory approach and it’s ok if we have one actor on the stage. But as we’ve introduced two actors, we should separate their inventories. Now we have one illogical thing. It doesn’t matter who picks up the book, both have the book in the inventory. This is the global inventory approach and it’s ok if we have one actor on the stage. But as we’ve introduced two actors, we should separate their inventories.
 
wmebook/ch6.1199962842.txt.gz · Last modified: 2008/01/10 12:00 by metamorphium
Recent changes RSS feed Creative Commons License Driven by DokuWiki