Can somebody clarify activation regions for me?

[imagremlin]

I just dont get activation regions. At first I thought they were meant to define my levels. Not so.

Seems to me they're more like destroy groups. You group actors you want destroyed together inside one. So. Checking my undestanding:

1) all actors get assigned an activation region
2) Any actor that does not intersect its activation group or the view gets destroyed.

My problem is that I placed activation regions around my levels, but things started to get weird as soon as I moved out if my first level. After some hunting I discovered that my main actor (the one the player controls) was getting destroyed at odd moments. Problem seems to be, that it got assigned to the first activation region. Is there any way I can have it assigned to NO REGION? I tried moving it out of all regions and did not work.

Am I correct in my deductions?

[Killagram]

The moment you leave an activation region, everything in it is destroyed. Since view determines activation regions' effects, the main way to make an actor survive is to make it a child of view. This is what child/parent means, that it shares xy with the parent. This is much different than simply mimicing the xy of an actor.

This makes activation regions somewhat difficult to use (because chances are player is not a child).

The best solution i can give you is to allow actors to overlap regions, for instance, if player 1 is 32 pixels wide, and the two regions are 30 pixels apart, player1 will be in both regions at once. He will not die in the transfer.

With your score, healthmeter, etc. the solution is to make them children of view. View's children will always be in the active region.

You can either spawn actors in the new region or make them children of view, then unchild them once they're in the new region.

Its a case of 'the best things about this feature' are also 'the worst problems with this feature'.

To compare it to the 'rooms' that other game making software uses; you have to place each actor in every 'room' or 'activation region' it will appear in;

Yes, it is an issue. But if actors survived from one region to another, then what would activation regions really mean? They are there to destroy unused actors!

One final note: Activation regions only work in exe format; they don't work the same in the editor preview mode. So always test your exe to see what they're actually doing.


I hope this post helps and doesn't confuse further.

[imagremlin]

I see. That confirms my suspicions.

Yet I still can't see a logical reason for having the main actor be assigned an AR. This actor should never be destroyed by anyone but me. I should be able to say, for the actor of my choosing (for instance, in the actor control window) Do not assign to an AR, never destroy or whatever. As it is, this renders ARs next to unusable i.e. they're just far too painful to use.

I'm now wondering what my options are for having more than one level.

[Killagram]

Like i said, the activation region is only doing what it's supposed to do.

Try making player a child, then unchilding him once you get to the new region.

[imagremlin]

Now its working. Its not that simple. I want to describe my findings for everybody's benefit.

My First Attempt (which does not work)

Code: Select all

  ChangeParent("hero", "centerview");
  MoveTo("centerview", 0.000000, 0.000000, 999.000000, dest, "");
  ChangeParent("hero", "(none)");


dest is a "reference" actor which is not drawn, I use these actors to set points to move hero to.

Looks sensible doesn't it? But Hero kept getting destroyed. By changing the speed to 10 I was able to see what was happening. Turns out Hero was still colliding with my platforms, getting hurt by enemies and anything else on its path. Gravity was also doing its thing so hero was also falling. Eventually one or more of these would push him out of the view, and consequently destroying him.

So my revised code to reliably move hero around (I made it into a function)

Code: Select all

void MoveHero(char *dest)
{
  EventDisable("hero", EVENTALL);
  playing=0;
  invincible=1;
  hero.yvelocity=0;
  hero.xvelocity=0;

  ChangeParent("hero", "centerview");
  MoveTo("centerview", 0.000000, 0.000000, 999.000000, dest, "");
}


I just had to make sure nothing was bothering hero on its path. The variables I'm setting are controlling all of these aspects. playing=0 turns off gravity. invincible=1 so my enemies don't damage hero. If you don't have an invincibility cheat you need one. Finally, make sure hero ain't moving. Then, and only then, move.

Things are restored back to normal at centerview's Move Finish event.

Another tip, I had to make sure hero never, ever leaves the view. I was using the centerview technique from the tutorials, which gives the game camera a nice "bounciness". It looks far more professional than parenting the view to hero. But with this technique, hero can fall out of the view when falling a long way. To correct this, I made this change to centerview's Draw Actor event

Code: Select all

if (playing)
{
   int weight=20;
   
   x = ((weight - 1)*x + hero.x)/weight;
 
   weight -= (hero.yscreen*15)/450;

   y = ((weight - 1)*y + hero.y)/weight;
}


My game is 640x480. What this does is decrease the weight as hero approaches the bottom of the view. This way, the view moves faster and hero never falls out of it.

[Killagram]

That is a very interesting take on it all. I'm very excited to see you do this because most people create multiple ged .dat files to create separate levels (imho, more work than its worth).

Multiple files creates exponentially more work for the programmer, which is never a good thing.

I hope this method works out for you in the long run ( you never know for sure until you have a total finished game).

But you have attacked this problem from a similiar angle to what i would have done, and explained a bit about regions to all.

Muy bueno!

[DilloDude]

See this topic for my assesment of various level methods.
Hope you find this helpful.