Deleting plans at runtime

[durnurd]

I'm curious: why does each map have the plans it has defined as member variables rather than storing them in a list?  The reason I'm asking is because if they were stored in a list, it would make what I'm asking for much easier:  Deleting plans at runtime.  That is, after a plan is finished, remove it from the map so it doesn't even get processed any more.

Another thing that would be nice, if a bit more difficult, would be the ability to specify outside the rules list when a plan should even be considered for execution based on one thing in particular, such as where a specific sprite is (i.e. the player sprite).  If the player sprite is at the top right corner of the map, and the plan only does something if the player sprite is at the bottom left corner of the map, and there are a significant number of plans that depend on the player sprite's location, then it would make sense to partition the plans into sections and check to see which section the player sprite is in and if the player sprite is in a section with plans that depend on this variable, execute those plans, otherwise, they never get ExecuteRules called on them.  This would help because then you don't have to check whether the bounding box of the player sprite and the plan overlap for every single plan that depends on this.

I suppose this could be generalized by something like Plan Groups, or something, where you can group plans together spatially (This could be done manually by the person editing the map, or maybe automatically as a tool that can be run in the map editor) and specify a condition that must be true for any of the plans in that group to be executed (i.e. Sprite is within the plan group's bounds).  A plan group could either be a plan with children plans, or just have its bounding box defined by the union of all of its children plans.

[bluemonkmn]

Plans are defined as variables so they can be referred to by name.  I guess it's similar to Visual Basic .NET.  In previous versions of Visual Basic you could have control arrays, but considering you're not usually going to have a huge number of controls defined at design time (in the designer), it made more sense to simply give every control a name and do away with control arrays defined in the IDE.  So now in VB .NET, you don't have control arrays any more.  If you want an array of controls, you have to create it in code.  Similarly, thinking about doing something "smart" with region-based rules in a map (as an optimization for huge numbers of plans), I didn't see that as a common use case in the IDE.  So I didn't put the effort or complexity into the IDE/framework to support that.  The philosophy behind SGDK2 was to move away from late-bound scripting approaches and toward early-bound pre-compiled code.  The fact that you can directly refer to any specific plan by name and access properties specific to that plan is kind of an optimization over the late-bound approach of potentially looking through a list and potentially type-casting the item to access its members.  I expected that the number of plans would have to be impractically large (as far as the IDE designer is concerned) before the performance would become an issue for simple rectangular overlap checking.  I did not think that plans would often be used in combination with non-player sprites, so multiplying the number of plans by the number of sprites testing against them does not seem like an important issue to me.

So to address your issues, my thought would be that there are a number of other ways to accomplish this:
1.Combine multiple plans into single plans.  For example, you could have your lower left map region be covered by a single plan.  You could a) define a number of other plans within it, or b) add lots of coordinates to the one plan, but in either case, just don't put any rules in a multitude of other plans... all the rules would be applied based on the single large plan.  The combined plan could test if a sprite is within its region of the map and then apply rules to those sprites based on its smarter data and rules.
2. If appropriate use tiles to trigger special behavior based on a region of the map.  Tiles, unlike plans, are intrinsically smart about the region of the map to which they apply.  When a sprite is interacting with tiles, it knows which tiles are close to it and only processes those.  Perhaps a single plan could be smart enough to apply rules based on the tiles in the area of a sprite instead of having to repeatedly define the plan for every case.  (For example, apply a rule that always transports the player from a red doorway to the nearest a red platform when the player touches a red doorway.  This makes level design much simpler too.)
3. Use sprites collisions instead of plans to trigger special behavior.  Sprites can be grouped, unlike plans.  Because sprites are often much more numerous and can have a much greater number of interactions (multiplying by the number of other sprites), it made sense to be a little smarter in the design of sprite interactions.