Download
1 / 13
130 likes | 229 Views
Chapter 9. Managing State. Action Objects. Definition: any object that requires its state to be tracked, is responsible for changing another object’s state, or imparts information to the player
E N D
Chapter 9 Managing State
Action Objects • Definition: any object that requires its state to be tracked, is responsible for changing another object’s state, or imparts information to the player • Information about its description, animations, sound effects and other properties associated with the transitions into other states and how it effects other objects must be stored.
Test Plot • Must decide how everything should happen in scene • This will make states of action objects more obvious • Should list action objects that may included in inventory
Stunt Doubles • A second version of an object to be used for a special purpose • Allows for more freedom with animations • Can use texture images of the objects as cursors or in inventory
State Machines • Transition from one state to another • Current state • Triggering event • Resulting state • Actions to be performed during transition • Pick Event • Common means for triggering a transition • See figures 9-1, 9-2, and 9-3
Application of State Management • State Management Tables
Lookup Table • Allows for more flexibility • See table 9-3
Evaluating the Results At this point, you now have the information you need to set things in motion. The order of evaluation is as follows: 1. To start, you have to know which object was picked. 2. You will then have to determine the object’s present state. 3. And you will have to know what the current cursor object was that picked it. 4. Next, using that information, you have to see what state the object goes into. Once you have that information, you can do the following: 5. Find and perform all of the actions (animations, sound effects, custom scripts, etc.) associated with the transition into its new state. 6. Check to see if there are any other objects affected and, if so, the states they will go into, so you can do all the associated actions for them as well.
Game Notes • Text document to keep track of conventions and rules for game
Action-Related Messages • Text to explain what happened during action • See Interactor script
Summary In this chapter, you started looking deeper into object state and how to manage it. By introducing a mini-plot for your game and a list of action objects, you were able to see the need for mapping out the actions and reactions of object/player interaction. You explored several different means of visualizing what states objects would need, which objects could interact with others, and what actions would be initialized upon interaction. You found that flowcharts could be valuable to map out simple interaction and state, but once you allowed objects to influence or change each other’s states, those models quickly became unwieldy. You got familiar with the common terms used in state machines. To move an object from one state to another, you found that you needed its current state, an event to trigger a transition, all the actions involved in that transition, and, finally, the new state the object would be put into. Actions, you found, are always associated with the state the object is going into. Simple state diagrams provided a means of listing state, associated actions, and animations, as well as how objects transitioned from one state to the next. By the time you tested state diagrams against multiple interacting objects, they were also starting to get complicated. The next step was to take the state diagram information and populate a table with it. At that point, you were getting a clearer idea of the data you had to work with and the critical path needed to process it. To simplify, you handled the state transitions independent of their associated actions. You then defined the possible states available to an object, listed the possible triggering objects (usually a cursor, default or otherwise), and any auxiliary objects and the states they would be put into as a result of the primary interaction. To store, manipulate, and manage the transitions, you created the first version of your ObjectLookup script. You found you could enter your pertinent data as a string into the built-in arrays available to the Inspector and later parse the string and separate the contents of the string into individual elements of a new array. Next, you started fleshing out your Interactor script to be able to hold all of the object’s transition action information, its metadata. By storing everything you need to know about the object in whatever state it is in, you are, in effect, creating a smart object. Using arrays, you can now store the object’s short and long descriptions, location, animation, audio, and other properties you wish to access by state. You also learned that you can keep the definitions and logic behind the setup stored in a text asset for quick access in the scene. Finally, you were able to test the basic implementation of your state machine, using a few of the test objects. The event, mouse pick, transitioned the objects to their specified states, playing sounds and animations that were stored on the objects themselves In the next chapter, you will get more creative with a few of the action objects’ transitions.
