Shattering objects without creating new ones in Unity - c#

I'm crating mobile unity game where a player will be hooking flying islands with a rope. I want the islands to sometimes destroy when pulled to strong by the rope.
I know that normal way of shattering objects is to destroy previous object and spawn its parts at the same place, but it won't work in my case, because I want the rope to remain hooked to one piece after shattering the object (same part of the object that it was hooked to before).
The only solution that came to my mind is to have these objects always created from separate parts, but connected with joints or script. Then they could be broken into separate pieces on some condition. I'm not sure if this solution is good or if there is better one, it would be great if someone could help me with this.

"I know that normal way of shattering objects is to destroy previous object and spawn its parts at the same place,"
There is no other possibility, whatsoever. That is how you do it.
Even if you dynamically create the new objects, you still do exactly what you say in that sentence.
"but it won't work in my case, because I want the rope to remain hooked to one piece after shattering the object (same part of the object that it was hooked to before)."
There is no problem whatsoever.
You simply hook that new piece to the rope. It's that simple.
Before .. one large piece "A" and connected to the rope at some point
After .. seven pieces "B" through "H". One of them (say "F") is connected to the rope.
You're done.
The only solution that came to my mind is to have these objects always created from separate parts, but connected with joints or script.
Yes, you can absolutely, totally do that.
Note that when you say "connected with joints or scripts". It is far easier that that!
Say you have seven pieces, named "1" through "7"
Have an empty game object called "Holder"
Just put the 7 objects "under" holder - i.e. holder is the parent.
It's that simple - nothing to it. Go for it!
Treat "holder" as one object. So if you want to move it or whatever, just move "holder".
If you prefer ...... let's say that small-piece "3" is the "one" which is attached to the rope.
Simply, make all the rest (1,2,4,5,6,7) the children of "3". It will all simply move as one thing. That's perhaps even easier for you.
Again, you're done!
Regarding your good question of how to "make one children of parent object stop being children and be separate object"
Simple,
smallObject.transform.parent = null;
but more likely, you will have some "overall" object, right? Or, the large object is attached the rope perhaps.
Quite simply, change the parent of the small object to that parent of the large object
Transform currentParentOfBigObject;
currentParentOfBigObject = bigObject.transform.parent;
.. create or separate the small objects ..
smallObject.transform.parent = currentParentOfBigObject;
.. perhaps get rid of the big object if relevant ..

Related

Architecture philosophy - should objects store information about the world?

I'm making a tetris-like game.
There are two classes in the game: simulator and block (i.e. a tetris block)
Right now, block only holds information about itself that is independent of any other parts of the game. So it's information like "shape", "color", "rotation" etc. (Notably excluding position)
simulator on the other hand, contains an data structure of block's and is responsible for their behaviours (falling, etc.)
Currently, to track the position of each block, simulator actually has an array called array_block_position, which is an array containing sub-arrays in the form of [block-instance, position], e.g. [block#3, (10,12)]
Now, I have this dilemma:
I am tempted to add a "position" variable inside the block class itself instead of tracking their positions in simulator, so simulator can have an array of visible_blocks that is simply an array of block instances rather than an array of arrays. (Visible is emphasized because there may be blocks that are not a part of the playing field, such as the block that is about to be deployed but not yet)
I am uncertain whether I should add "position" as a variable to the block class itself because of some vague memory of learning that this being a bad idea in college, but I no longer remember why it's supposed to be bad, if at all.
I want to know, in general, whether (and when) it's acceptable to store information about an object's relationship with the external world inside the object itself.
(My instincts tells me "no", because a variable like "position" is not meaningful to an object like block without some reference to the external world, but my reasoning sees no immediate problem with something like this in practice)

C# / Unity - Need help debugging my Chess program - trouble creating instance of class within another instance of the same class

I'm creating a Chess program. I've decided to make it so that, when a piece is selected, all of its possible legal moves are displayed. In order for that to work, I have to have a mechanism to predict the outcomes of moves (because you can't make a legal move which puts your own king in check, for example). This will also be useful when I start working on computer opponents, since the AI will need to be able to see several turns in advance in order to make intelligent decisions.
To this end, I've made it so that, at the start of each turn, all possible moves are calculated for the player's pieces, and then each of those possible moves is simulated to see whether or not it leaves the King in check. If so, that option is removed. I have a main class called BoardManager which controls the visuals and contains the actual chess board layout (in a ChessBoardSim), and I have a class ChessBoardSim, whose objects each contain one possible board state. ChessBoardSim can create other instances of ChessBoardSim, allowing the state of the board any number of turns in advance to be simulated.
I have a bug which I've been struggling with for over 5 hours, which appeared after I tried to restructure a lot of the code. I'm at my wit's end, and I just need a fresh pair of eyes. The issue is making it so that pieces aren't being removed from their old positions when moved, and the locations of some of the pieces on the board seem to be shifted two tiles up. I believe, based on the debugging, that the problem is appearing in CalculateAllMovementOptions() in the ChessBoardSim class - for some reason, when a ChessBoardSim has a ChessBoardSim child and the CalculateAllMovementOptions() function is called in the child, it changes the data in the parent.
I've included the full code below, and I'll describe the specific issue as best I can.
The flow of the problem is:
1: private void Start() in BoardManager is called.
2: The program draws and populates the board properly. A ChessBoardSim (called ChessPieces) is created to contain the data of the current board state.
3: StartTurn() is called in BoardManager, in order to begin the game.
4: StartTurn() calls ChessPieces.CalculateAllMovementOptions(). The intended function of CalculateAllMovementOptions() is to get back an array of Lists. Each List in the array contains the legal moves of one of the player's pieces. However, this actually seems to be changing the actual board data, and I can't work out why.
When a player tries to move a piece, the game breaks because the pieces aren't where they're supposed to be and the software can't cope with it. The piece which is moved doesn't remove itself from its old location (despite my best efforts), and this causes there to be two instances of that object, leading to an indexoutofrange exception when a piece of the code tries to access the 17th element of an array with 16 elements.
I would really appreciate it if anyone could help me, I feel like I've wasted an entire day on this already and I'm sure I'm missing something simple.
The link to my code is https://github.com/FC123321/Chess
Array.Clone doesn't create a deep copy of an array, so when you call boardLayout.Clone() in SimulateBoard (and again in the ChessBoardSim constructor), you are copying the references in boardLayout to the new array. This means that the pieces in the new array are the same object in the old one.
This means that when you're in MovePiece in SimulateBoard and you call piece.SetPosition and such on members of that copied array, you're setting the position of the pieces in the source of the copy as well.
Instead of using boardLayout.Clone(), you need to loop through the whole source array, and do newBoardLayout[x,y] = new ChessPiece(); and then copy over the values to the new ChessPiece. Alternatively, you could create a new ChessPiece constructor that takes another chess piece and copies the values there:
// ChessPiece copy constructor
public ChessPiece(ChessPiece other) {
this.Position = new int[2] { other.Position[0], other.Position[1]};
this.isWhite = other.isWhite;
this.movementType = other.movementType;
this.hasMoved = other.hasMoved;
this.turnDoubleMoved = other.turnDobleMoved;
}
// instead of boardLayout.Clone() in the ChessBoardSim constructor:
for (int x=0 ; x<8;x++){
for(int y=0; y<8;y++){
if (boardLayout[x,y] != null)
this.boardLayout[x,y] = new ChessPiece(boardLayout[x,y]);
}
}
// In SimulateBoard, take out the redundant Clone call
ChessBoardSim simBoard = new ChessBoardSim(boardLayout, turnNumber);

Data structure for simple animations in games

I'm trying to create a system in which numbers are changed according to the time elapsed since last update, their target/destination value, etc.
In an earlier project, I created an abstract class for animation data which contained Tick(), IsDone(), etc, which were then implemented for each facet of the game object I wanted to animate, such as position and opacity. The animation data were held by the game object, with the Tick() function being called by the game object's Tick() function, which is called by the engine's logic update loop using a list of all game objects.
However, I now have more things I want to animate, and was looking in to doing so with as few classes as possible, and definitely not with N+1 classes.
I looked in to saving references to the variable being animated, using the fact that all variables I wanted to animate were floats. However, it appears C# pointers are analogs to the C pointers, and so I cannot save pointers to the values being animated, which appears to be impossible for the CLR in the first place.
The only alternative I could think of is to use reflection to record the argument being passed, then use reflection again to find the value to alter each tick. But then using dozens of reflection calls 60 times a second did not appeal to me.
Since animating objects is a near universal feature in games, I was wondering if there were established practices.

Property of one class is another class, and vice-versa

I'm programming a board game in C# where the two most important classes are Piece and Square. Typically every instance of Piece has a Square (as a property) and every instance of Square may have a Piece (also as a property) or may be empty.
I placed code in the set methods of Square.Piece and Piece.Square to ensure that this relationship was maintained (e.g. when a piece is moved from one square to another) and to avoid the obvious danger of the linked properties calling each other's set methods in an endless loop.
But when a piece is removed from the board and its square set to 'null' I seem to have too many if statements to avoid null exceptions and what seemed a very simple pattern conceptually becomes far too complex and error-prone in practice.
I'm wondering whether my whole approach is wrong. Should a piece have a square as a property when Square also has Piece as a property? Have I in fact started coding an anti-pattern? A Piece's Square may be null on creation, and a Square's Piece is frequently null (representing empty). Should I use another way to represent empty Squares and Pieces which are not on the board?
I'm assuming there are preferred, robust solutions to the more general case of when one class is linked to another in a two-way relationship such as this.
Many thanks for any ideas.
Use an higher level abstraction, with methods like
move(piece, originalSquare, destinationSqueare)
place(piece, square)
remove(piece)
promote(originalPiece, finalPiece)
...
these methods will use your basic methods from Piece and Square, and will be the ones used by your main logic
It seems to me that you're overthinking the process of removing a Piece from the Board.
The game is going to be centered on the Board class. Once you remove a Piece from the Board, that piece is gone; you're not going to do anything with it anymore. You won't be calling any of its methods or anything. That object is now dead -- unreachable. So there's not actually any reason to change the Piece's state to null out its Board reference.
This is indeed a very common pattern, and the usual practice is to just let it go. Once nobody references the Piece anymore, you're done; it no longer matters that the Piece still happens to reference the Board. Let it keep its reference; it won't cause any harm (since nobody will be doing anything with that Piece anymore), and it'll be garbage collected soon anyway.

Coding interactions in a text adventure

EDIT: If you can't be bothered to read this mammoth question, I've put a summary at the bottom.
I'm currently working on a sort of "framework" for a text adventure I am going to make in C#, as a coding excercise. In this framework, possible actions are defined by an "Interaction" class.
The potential "Actionable" objects are Inventory Items (stick, gun, sword), Environmental Items (wall, door, window) and Characters (people, animals). Each of these has a property which is a List of Interactions. At the moment, an Interaction is basically an "action/response" name value pair. When you type "smash window", it looks through all possible actionable items that the Player has available and matches the subject (in this case, "Window"). It then works out that the action is "Smash" and looks up in the List of Interactions on the Window (Environmental Item) to get a response for the Smash action and then writes it to the console.
That is all done, but here is the point that I am stuck:
An action has any number of potential consequences, which differs by each potential interaction. These are:
- Returns a response describing the result of the action by looking it up on the interaction, possibly with a second subject
EITHER
- The subject of the action (inventory item, environmental item or character) changes it's description
EG. "punch wall" could change the wall's description to describe a dent in the wall
OR
- The subject of the action is replaced by another item
EG. "smash bottle" results in "bottle" changing to "broken bottle" or "kill John" results in the character John being replaced by environmental item "John's corpse".
- Returns a response describing the preceeding change
EG. "The broken pieces of the bottle are scattered across the floor."
- An area's description is changed.
EG. "smash lightbulb" results in the room's description changing to describe a pitch black room
- Items are added/removed from the inventory or the environment
EG. "pick up bottle". You now have a bottle in your inventory, and the bottle is removed from the environment.
- The directions available for movement and the areas which they lead to are changed
EG. "unlock door with key" allows you to move East into another room
- The player is moved to a new area
EG. "go north" takes you to another area.
I need to somehow determine in a generic way which of these consequences a particular Interaction should invoke, and invoke them. An action could potentially use a number of these consequences, or just one.
For example, if the item is a Bottle:
"fill bottle with water" would first return a response describing that you have filled the bottle with water. It would then replace the "bottle" item with a "bottle of water" item.
That is two consequences, returning a response and replacing an item.
Say you were then to do "throw bottle of water at window". This is more complex. It would first return a response describing the events that take place, the bottle and the window would both smash and water would go everywhere. The bottle would be removed from the Player's inventory.
Next, the "bottle of water" would be replaced by the "broken bottle" and the "Window" would be replaced with "Broken window". The area description would also change to reflect this.
That is five consequences, returning a response, removing an item from inventory, replacing two items and updating the description of the current area.
As you can see, I need a generic way of being able to define on a per "Interaction" basis, what the consequences of that action will be and update other objects such as Item, Player (for inventory) and Area appropriately.
I'm sorry if this is unclear, and I will do my best to clarify if anyone has any questions.
EDIT: Is there a way for me to define a method on an Interaction that I can pass a number of methods to call (and their parameters) into? The initial response returned would be the default, mandatory consequence, and then there could be extra ones if specified.
For example, in the examples above, for the first interaction, "fill with water", I would tell it to return a response ("You have filled the bottle with water") and also to call a ReplaceItem method that would replace the "bottle" subject with a "bottle of water".
For the second interaction I would tell it to return a response ("The bottle hurtles through the air into..."), call RemoveFromInventory on the subject of the action, call UpdateStatus on the bottle ("the bottle is smashed") and the window ("the window is smashed") and call UpdateAreaDescription to change the current area's description ("You are standing in a room with a single window, the glass smashed to pieces").
Does that sound feasible? I'm trying to keep this as generic as possible, for the sake of all the different possible interactions.
EDIT 2: To clarify further, and to attempt to summarize the problem:
In my game, there are Actionable objects (a bottle, a wall, John). Each Actionable object has a list of
Interaction objects which describe how a player can interact with them. At the moment, an Interaction has a
"Name" property ("throw", "hit", "break") and returns a Response ("You throw the ").
The issue that I am trying to resolve is that an Interaction also needs to do a number of other things, varying
by each particular Interaction. Let's take the example of a glass bottle.
"throw glass bottle"
- A response is returned ("You threw the glass bottle.")
- The "Bottle", is removed from the Player's inventory.
- The is replaced with a new to reflect the change. ("Bottle" replaced with "Broken bottle").
- A second response is returned ("The pieces of the glass bottle are scattered on the floor").
"throw glass bottle at window"
- A response is returned ("You threw the glass bottle at the window.")
- The object "Bottle", is removed from the Player's inventory.
- The object is replaced with a new object to reflect the change. ("Bottle" replaced with "Broken bottle").
- A second, optional object is replaced with a new to reflect the change. ("Window" replaced with "Broken window").
- The "Description" property of the current Area is updated. ("You are standing in a room, with a single broken window.").
When I create the Interactions, how can I vary the additional actions that they perform, such as status changes
to the subject, or changes to the current Area's description?
If you need more examples of actions as above, let me know and I'll do a few more.
I think you should decide on a set number of verbs you will recognize, and then for each object decide which of those verbs it is capable of responding to.
Lock Object Recognized Verbs
Look
UseItemOn(Key001, LockPicks, Sledgehammer, ...)
Punch
That way you can generically handle verbs it doesn't recognize with a response like "You can't <verb> the <object>, and handle verbs it does recognize with events or whatever.
Edit
As per your comment I obviously just scanned your question (too long for me). Still, I don't see the difference, really. The point is, an object participates in an event. From the Bottle's perspective, it gets hit by a wall. From the Wall's perspective, it gets hit by a Bottle. Both objects will have a list of verbs to which they will respond in a certain way.
So if you plan for the wall to be responsive to ANY thrown object, then you'll need to add a Collide verb to its list. You'll want to specify which objects it should care about colliding with, and maybe for each of those, how it should respond to particular magnitudes of force, etc.
But the principle is the same. For any event there are a number of participants, and each participant will have certain stimuli it cares about, and for those stimuli it will have certain stimulus origin objects it cares about. If it's a verb it cares about but its origin is not an object it cares about, then it will effectively ignore it - or respond in some vanilla fashion.
The Bottle participates in a Collision with the Wall. The Bottle has in its Verbs list the Collide interaction type. It may have a single object with which it cares about colliding, or it may have a value of Any, or AnySolid, or whatever. There's a million ways to architect that. In any case, the Wall also participates and may also have in its Verbs list the Collide interaction type. But it only cares about colliding with the Sledgehammer object - or maybe AnySolid that has a Mass of 10 or greater...
You could also do this with interfaces. You can have an LootableObject that implements ICollidible interface, or whatever. When any ICollidible (say, a bottle) executes its Collide method it will need certain parameters: how fragile it is, how much force it received, whether the colliding object is something it cares about, etc.
It may be full of liquid so it would implement an IContainer interface which has a Spill method, and also an IConsumeable interface which has a Drink method. It may be a lock which implements an ILockable interface which has an Unlock(obj Key) method and a Pick(int PickSkill) method. Each of these methods can produce certain changes in state to the object and the other particpant(s) in the interaction. You can do this with Events if you like.
Basically you need to decide what level of (un)predictability you want and then compose a matrix of interactions (not necessarily physics, but any kind of interaction you plan to operate on - a lockpicking event, a collision event, a drinking event) that involve certain predictable properties.
All actions you have described consist of the following:
A verb (for example "throw")
an object (for example "bottle")
an optional additional parameter describing the action further (for example "at window")
How about modelling each actionable object as a class derived from a common ancestor and have that class handle the action itself. Something like
public interface IObjectBase
{
bool HandleAction(string verb,string [] params)
}
public class Bottle: IObjectBase
{
bool HandleAction(string verb,string [] params)
{
//analyze verb and params to look for appropriate actions
//handle action and return true if a match has been found
}
}
You've got two things: the player and the environment (you might also have other players).
Pass them both to each interaction:
interaction.ActOn(environment, player);
//eg:
smash.ActOn(currentRoom, hero);
Then let each interaction work out what to do:
environment.ReplaceObject("window", new Window("This window is broken. Watch out for the glass!");
player.Inventory.RemoveObject("bottle");
player.Hears("The window smashes. There is glass all over the floor! If only John McLane were here...").
With the usual checks to make sure that the environment actually has a window, the player has the bottle, etc.
player.Inventory.ReplaceObject("bottle", new BottleOfWater());
Interaction then becomes a common interface which you can attach to anything in the system, be it an environment, player, bottle, etc. You can probably work out some particular types of interaction which you can use to remove duplication, but I'd start simple and go from there.
See also Double Dispatch.
Hah, I'm working on something similar too.
I'm wondering if your framework ends up becoming a text-adventure creator which is what my project is.
My approach is to have a sort of API that consists of methods that represent all the most basic actions in the game. Then use 'scripts', which are basically methods containing a combination of these basic actions.
These basic actions may involve:
Print a message
Change an object's/room's description
"Lock" or "unlock" an object. This means that "examine belt" will say "You don't seen any belt here" UNTIL "examine corpse" has been performed to learn that "The corpse has a shiny belt around its waist".
Lock or unlock exits from a room
Move the player to some room
Add/Remove something from the player's inventory
Set/Change some game variable eg. "movedGlowingRock = true" or "numBedroomVisits = 13" etc.
and so on... This is what I currently have in mind.
These are all methods in maybe an API class and take various parameters as necessary.
Now, there are rooms. Rooms have objects. Certain commands are valid for each object. One simple way is to have each room object hold a Dictionary of allowed commands. Script is a delegate that points to your action script. Ponder this:
delegate void Script();
class GameObject
{
public Dictionary<string, Script> Scripts {get; set;}
public string Name {get; set;}
//etc...
}
And your scripts, stored in the relevant Room instance:
//In my project, I plan to have such an abstract class, and since it is a game _creator_, the app will generate a C# file that contains derived types containing info that users will specify using a GUI Editor.
abstract class Room
{
protected Dictionary<string, GameObject> objects;
public GameObject GetObject(string objName) {...//get relevant object from dictionary}
}
class FrontYard : Room
{
public FrontYard()
{
GameObject bottle;
bottle.Name = "Bottle";
bottle.Scripts["FillWithWater"] = Room1_Fill_Bottle_With_Water;
bottle.Scripts["ThrowAtWindow"] = Room1_Throw_Bottle_At_Window;
//etc...
}
void void Room1_Fill_Bottle_With_Water()
{
API.Print("You fill the bottle with water from the pond");
API.SetVar("bottleFull", "true");
}
void Room1_Throw_Bottle_At_Window()
{
API.Print("With all your might, you hurl the bottle at the house's window");
API.RemoveFromInventory("bottle");
API.UnlockExit("north");
API.SetVar("windowBroken", "true");
//etc...
}
}
All this is sort of a skeleton view of what I have in mind (there are many subtleties I have noted, but this is good enough for an example). Sadly I haven't even coded a single word for my project, hehe. Everything on paper.
So...all this might give you some ideas to tinker with for your own project. If something is unclear, ask. Hope I haven't strayed from your question or something.
I think I spent too much time typing all this >_>
EDIT:
PS: My skeleton example doesn't exactly show how to manage commands involving multiple game objects (This is just one of the many subtleties I hinted at). For stuff like "throw bottle at window", you need to think up how to manage such syntax, eg. a taste of my solution to this is to parse and discover what command is being issued... "throw GO at GO". Find out what the game objects are, then see if the current room has them. etc etc.
More importantly, this also prevents you from holding scripts inside a game object instance, since one command involves more than one game object. Probably better to store the Dictionary in the Room instance now.
(This is sort of where I am with my project.)
Pardon my ramblings... >_>
It seems like your issue is managing propagation of events. Microsoft handles this issue (for less colorful purposes) using the Observer pattern/events.
I think the combining the Observer and Mediator design patterns from Gamma,etc.'s book "Design Patterns" would be very helpful for you. The book has a sample ChangeManager class that might be helpful, but I have attached some other links that should serve you well.
One implementation suggestion I have would be to use a static or singleton class that acts as the mediator and also stores references to all of the actionable objects in active memory as well as all of the invoked actions. This class can process the algorithms to determine all of the responses and the chronological order of the responses from a given action. (If you consider that the collateral-effects of a primary action, A, can affect the consequences of that action, A, prior to the action completing, it would become evident that the proper chronological sequence is necessary, and must update before invoking each collateral action.)
Microsoft's article on the observer pattern: http://msdn.microsoft.com/en-us/library/ee817669.aspx
DoFactory on Mediator pattern (with UML diagrams): http://www.dofactory.com/Patterns/PatternMediator.aspx
DoFactory on Observer pattern (with UML diagrams): http://www.dofactory.com/Patterns/PatternObserver.aspx
IObserver interface documentation in .Net 4,
http://msdn.microsoft.com/en-us/library/dd783449.aspx
another article on the observer pattern. http://www.devx.com/cplus/Article/28013/1954
Interaction can be defined as "Verb + {List of Filters} + {List of Responses}"
For your "fill bottle with water" example, the Interaction would be:
Verb: Fill({"fill", "pour"})
List of Filters: Have(player, "bottle"), Have(currentRoom, "water tap")
List of Responses: Print("You filled the bottle with water"), Remove(player, "bottle"), Add(player, "bottle of water")
alternatively, List of Responses can be: SetAttribute(player.findInventory("bottle"), "fill", "water")
Then if you need to "throw bottle of water at windows":
Verb: Throw({"throw", "smash"})
List of Filters: Have(player, "bottle of water"), Have(currentRoom, "windows")
List of Responses: Print("The bottle smashed with the windows, and both of them are broken"), Remove(player, "bottle of water"), Add(curentRoom, "broken bottle"), Remove(currentRoom, "window"), Add(currentRoom, "broken window"), SetAttribute(currentRoom, "description", "There is water on the floor")
Upon entering a Room, the Framework will query all objects in the room for a list of valid Verbs, and enumerate them. When the player enters a command, the framework searches for a Verb that matches the command; then it will check the list of Filters, and if all of them is True, then iterate through the List of Responses to execute them in order.
The Responses would be a function object which implements the IResponse interface which has some constructors, and a IResponse.do() method. The Filters will be function object which implements the IFilter interface, again with some constructors, and IFilter.check() method returning a boolean. You can even have And(), Or(), and Not() filter to make more complex queries.
You can make things even more readable by having some convenience methods, a Player could have Player.have(Actionable) convenience method so you can write player.have("bottle of water"), which returns not the bottle object itself, but an IFilter object that will check whether the player have "bottle of water" when its .check() method is called. Basically, make the objects lazy.
Alright guys, here's how I handled it. It was the most generic way I could think of and I think it suits what I am trying to achieve.
I added an "Invoke()" method to the Interaction class, a new Interface called IActionResult which defined an "Initiate()" method, and a number of different ActionResult types for each possible consequence. I also added a List of ActionResults to an Interaction. The Invoke method would simply loop through all of the IActionResult objects and call the Initiate() method.
When you define an Interaction on an item, you would pass in a list of verbs for that Interaction and then add a number of ActionResult objects depending on the consequences of that Interaction.
I also added a GlobalActionReference, which would be updated each time an action is performed, and an ActionResult would have appropriate access to the objects it needs to update through this.
I really appreciate all of your suggestions, and I'm sorry if I wasn't clear with my question or my comments (or even this answer). Thanks for your help.

Categories

Resources