Separating behavior from Models

A key part of many games is spawning new objects.  In the paper about the therapy IDE, several of the games needed new objects to be spawned.  One needed pieces of trash or fish to appear and float down the river.  Another needed objects to be sliced to appear in front of the player, and one needed food pellets to drop to the bottom of a fish tank.

Faking New Objects

One way to handle this is to have a bunch of objects off screen or invisible in a kind of reserve.  When you need one, you simply move it into view, and it seems like it was just created.  This doesn't require any dynamic creation of objects as the program runs, and the behavior for all of the objects can be set in advance.  This was the approach I used for the Helicopter and UFO games.  However, this puts a hard limit on how many objects can move into the game world as well as forces you to duplicate logic for each of the objects in reserve.

The Spawn Box Approach

In the old IDE, there was the notion of the spawnBox which I mentioned last week.  It allows you to assign objects to it, and then spawn a copy of those objects at its location whenever you need.  An added bonus is if an object A has a collision handler with the original object B, this collision is also fired when A collides with B's copy.  The same is not true for a collision handler for B on A, meaning that B's copy colliding with A will not fire B's collision handler.  Obviously, this behavior isn't perfect, and it never claimed to be, but it is still a very useful idea.

I like the idea of creating copies of objects, and I also like the idea of those copies firing events like they are the original.  However, this should not just be limited to copies of the original object.  Two different fish should be able to fire the same event without having to be known about before hand.  This goes back to what I mentioned last week about having event listeners based on Class, but that puts some unnecessary limits on it.  

Roles

I would like to introduce the idea of Roles.  In their simplest form, they would just be a list objects of some common parent type like Movable.  When you handle events with this Role, you could call the methods of whichever specific object fired the event.  Then whenever you spawned a new object, you could assign it a Role and the events would already be in place.

In the underground water example, I would assign the fish, the shark, and the submarine to the "badGuy" role.  I would have an event handler for the collision of the UFO and a "badGuy".  Whenever this happened, the badGuy would make some kind of attack motion and your score would go down.  Then, I could spawn more sharks and fish and assign them to the same Role and they would behave the same way.

Advanced Roles

In this most basic form, the Roles are just a global list of objects of some similar type.  This could be extended to add specific methods and events to a Role so it essentially becomes a class of its own.  This would solve the problem of reskinning a game I discussed two weeks ago since you could just create a new model and assign it the role of BadGuy and you would be all set.  You could also have the methods operate on specific properties of the model, either physical or custom properties, which would allow for more customization as well as difficulty adjustment.  For instance, if you had a BadGuy role and you set his speed property high, his movement speed could be faster than a different BadGuy.

Pitfalls

One potential stumbling block for this approach are the complexity of the concept.  In this more advanced approach I just described, we're basically introducing OO programming.  This could be very difficult for people new to programming to grasp.  However, one of the key takeways from the Therapy IDE paper was that efficiency was very important to therapists.  I can only assume this will also apply to caregivers who will be using this IDE to create games.  Giving them powerful tools that will prevent them from having to duplicate a bunch of event logic will allow them to create games faster that are more entertaining.

Another potential stumbling block is integrating this into LG.  I can see if having fewer use cases in the storytelling version since there are not nearly as many event listeners and things like that.  An easy solution is to put this in the "Games" toolbox which we would only expose if someone opened up a Game template like Caitilin mentioned in the comment last week.