Author Topic: Suggestion for Plans and Sprites  (Read 13266 times)

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Suggestion for Plans and Sprites
« on: 2010-03-27, 10:00:37 AM »
It would be great if we could specify the superclass of specific Plans and specific Sprite Definitions.  The options would be from a list of abstract classes that extend from PlanBase and SpriteBase (presumably that do not implement the ExecuteRules method, although this point is contestable).

This way, if some sprites or plans share functionality, it can be in a shared superclass, but not in the base class because not all sprites need it.  It is also possible to override methods in this way, for certain sprites or plans.

My reason for this mainly is that I want a plan that does something exactly once, and if I plan on having an arbitrary number of these, I can't count on map flags to be plentiful enough.  It's easy enough to do, by just adding a boolean to PlanBase, but for two reasons I don't want to.  First, if I put it in PlanBase, I can't reset source code without losing it.  I could put it in a  partial class for PlanBase, but PlanBase is not a partial class itself, which means after I reset the source code, I have to go in and redeclare it as a partial class.  Second, the extra boolean would not be needed for other plans, only those that are to be activated once.
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2744
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Suggestion for Plans and Sprites
« Reply #1 on: 2010-03-27, 11:01:30 AM »
PlanBase is a partial class.  If it's not, then your project's source code must be old.  I can do this in a separate file with the current SGDK2:

Code: [Select]
abstract public partial class PlanBase
{
   bool done = false;
}

Sadly, I can't do this because plans are hard-coded to inherit from PlanBase:
Code: [Select]
abstract public partial class RunOncePlan : PlanBase
{
   bool done = false;
}

public partial class Level_1_Map
{
   public partial class Main_Lyr
   {
      public partial class Door_Left : RunOncePlan
      {
      }

      public partial class Door_Right : RunOncePlan
      {
      }
   }
}

However, this might be a good alternative.  You can create a class that generically handles any customizations you want to make to any plans:
Code: [Select]
abstract public partial class PlanBase
{
   protected CustomPlanInfo cust;
   bool IsPlanActive()
   {
      return cust.IsPlanActive(this);
   }
   public Coordinate GetCoordinate(int index)
   {
      return Coordinates[index];
   }
   public virtual void CustomInitialize() {}
}

abstract public partial class CustomPlanInfo
{
   public abstract bool IsPlanActive(PlanBase plan);
}

public partial class RunOncePlanInfo : CustomPlanInfo
{
   bool done = false;

   public override bool IsPlanActive(PlanBase plan)
   {
      return done == false;
   }   
}

public partial class ActiveWhenVisiblePlan : CustomPlanInfo
{
   public override bool IsPlanActive(PlanBase plan)
   {
      return (plan.ParentLayer.CurrentPosition.X + 800 > plan.GetCoordinate(0).x)
         && (plan.ParentLayer.CurrentPosition.X < plan.GetCoordinate(0).x)
         && (plan.ParentLayer.CurrentPosition.Y + 600 > plan.GetCoordinate(0).y)
         && (plan.ParentLayer.CurrentPosition.Y < plan.GetCoordinate(0).y);
   }
}

public partial class Level_1_Map
{
   public partial class Main_Lyr
   {
      public partial class Door_Left
      {
         public override void CustomInitialize()
         {
            cust = new ActiveWhenVisiblePlan();
         }
      }
   }
}

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Suggestion for Plans and Sprites
« Reply #2 on: 2010-03-27, 01:08:58 PM »
Two things:

first:  I had reset the source code, but apparently files that are currently open in the editor are not reset, so because I had that file open, it was not reset.

second:  Hard coded how?  My suggestion is some dropdown list in the plan editor or the map editor that changes the base class for that plan for when code generation happens.  Would that not work?
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2744
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Suggestion for Plans and Sprites
« Reply #3 on: 2010-03-28, 08:11:07 AM »
second:  Hard coded how?  My suggestion is some dropdown list in the plan editor or the map editor that changes the base class for that plan for when code generation happens.  Would that not work?

I was talking about the current SGDK2 implementation.  SGDK2 doesn't let you specify the base class -- it's hard coded to always inherit from PlanBase.  The above code shows you what you can do without changing any SGDK2 code.  Of course, if I changed SGDK2, it wouldn't be hard-coded any more.  But my assumption is that if I don't release another update soon, you'd still be interested in some way to accomplish this with the current SGDK2 code.

I know that if one file doesn't specify a base class for class A, then another file with a partial class for class A can specify a base class.  So I thought that we would be able to specify a base class for plans in a partial class.  But I forgot that SGDK2 does specify a base class, so we can't do it that way.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2744
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Suggestion for Plans and Sprites
« Reply #4 on: 2010-03-28, 09:12:09 AM »
I am going to re-implement the default framework code and SGDK2 code generator so that every ExecuteRules function generated by SGDK2 is implemented as "ExecuteRulesInternal" instead.  Then I'm going to make an override-able (virtual) function in the base class called ExecuteRules whose default implementation is simply to call ExecuteRulesInternal.  That way, every place that the generated code calls ExecuteRules, you have a chance to override what executes by overriding ExecuteRules in a partial class for the derived class.  For example:
PlanBase.cs will now implement

public virtual void ExecuteRules() { ExecuteRulesInternal(); }

And then you can add code in a separate file
Code: [Select]
public partial class Level_1_Map
{
   public partial class Main_Lyr
   {
      public partial class Door_Left
      {
         public override void ExecuteRules()
         {
            if (isPlanActive) // You could, for example, only execute plan rules under certain conditions.
            ExecuteGlobalPlanRules(); // You could, for example, run some code before any other plan rules.
            base.ExecuteRules();
         }
      }
   }
}

I am doing something similar for map ExecuteRules, so you should be able to put in a LimitFrameRate call in a map ExecuteRules customization too.

Of course, now it would be even more nice to be able to specify the base class for a plan, sprite, layer or map so that you didn't have to create a partial class for each individual object that wants to customize the ExecuteRules behavior.

Think this too is helpful?

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2744
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Suggestion for Plans and Sprites
« Reply #5 on: 2010-03-29, 06:28:49 AM »
Yesterday I managed to implement the "BaseClass" property for a Plan in the map editor.  Now you can see a dropdown list of other abstract classes that inherit from PlanBase.  When you select one, and then re-select the plan, you will see any public properties specific to that base class appear as properties in the property grid so you can initialize their values.  I have yet to implement BaseClass in the plan editor.  And I have yet to implement it for sprite definitions.

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Suggestion for Plans and Sprites
« Reply #6 on: 2010-03-29, 08:12:48 AM »
I meant to reply yesterday to your previous comment about ExecuteRulesInternal, but my tubes were down.

So if you combine the ability to change the base class with the execute rules internal, then you basically get something where you don't have to put an If rule at the beginning of every plan rule set (for example).  By itself, it doesn't seem to helpful, because all your example does is the same an extra if and an extra Do would do in the rule set.  But if you could have it be for every plan of that base type, it would be much more helpful.
Edward Dassmesser

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Suggestion for Plans and Sprites
« Reply #7 on: 2010-03-31, 05:38:02 PM »
Another comment about plans:  Is there a way to move them around at runtime or a reason not to have one?  Things like offsetting, scaling, and even rotating if the box bit doesn't matter.

And another one: Would it be possible to make paths with non-rectangular bounding areas?  That is, have plans with more than two points that can still check to see if things are inside of them.  I know there are algorithms to do it, at this point I'm just talking about the map editor GUI for displaying them.
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2744
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Suggestion for Plans and Sprites
« Reply #8 on: 2010-04-01, 06:44:54 AM »
It seems to me that there's little point in making the map editor display that.  The reasons I can think of are:
1. To demonstrate, "hey, guess what you could do if you wanted to".
2. To help the user remember which side of the line is the inside (There's only one that makes sense once the path is implicitly or explicitly closed).

The reason for doing the rectangles was to help visualize all sides and corners, but that's not necessary when all sides are already drawn.

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Suggestion for Plans and Sprites
« Reply #9 on: 2010-04-01, 04:43:06 PM »
1. To demonstrate, "hey, guess what you could do if you wanted to".

Yeah, but I totally want to!

Anyway, how about built-in algorithms for checking insideyness?
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2744
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Suggestion for Plans and Sprites
« Reply #10 on: 2010-04-01, 04:58:42 PM »
That could be fun to work on.  Do you think that's the most important thing after base classes for plans?

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Suggestion for Plans and Sprites
« Reply #11 on: 2010-04-01, 05:43:31 PM »
Well, I don't know what else there is to work on, so I've no idea.  My real need was to be able to move plans around, and the other ideas came after that as things that seem like they should exist, but aren't necessary for what I'm doing right now.
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2744
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Suggestion for Plans and Sprites
« Reply #12 on: 2010-04-16, 06:16:44 PM »
I implemented a function to check whether a sprite is within the polygon formed by a plan's coordinates.  I checked everything into SVN so you can test all this base class and polygon stuff.  Wanna try it?  If it looks good, maybe SGDK2 is ready for another release.

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Suggestion for Plans and Sprites
« Reply #13 on: 2010-04-17, 08:54:13 AM »
I did an update, and found that either two files are missing or they're supposed to be generated somehow.  When I opened the project, it couldn't find the .config files for opentk.dll and fmod.dll.  When I deleted the references to them in the project I was able to run the application.  Will let you know more once I try it out
Edward Dassmesser

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Suggestion for Plans and Sprites
« Reply #14 on: 2010-04-17, 10:22:53 AM »
Some more points:  One reason I wanted to make subclasses was so I could override functions like reactToSolid in the subclass.  There are plenty of ways to handle this, but it seems like the cleanest would be to have a subclass in between SpriteBase and the specific classes that use the overridden reactToSolid method.  The problem is that reactToSolid is not marked virtual and is in an abstract class, which means it can't be overridden properly.  I can use 'new' instead of 'override', but I'm not sure what the difference is, and if it would be a problem.

The OTHER problem is that reactToSolid needs to be able to access m_solidity and layer, which are declared private in the base class and there's no getter for m_solidity.  As it stands, I can get away with making the one change to SpriteBase to declare m_solidity as protected after resetting the source code and everything still works, so that's definitely a giant leap forward.
Edward Dassmesser