Inheritance

[AnarchCassius]

I just started working with Game Editor and I'm pretty impressed. I do have a question about inheritance though. Is there any way to track inheritance in scripts? For example I have a basic enemy type and a basic obstacle type, is there a way to, for example, check collisions for all descendants without having to manually specify each one?

[Game A Gogo]

clone the actor instead.

[again]

Or you can make an enemy and enemy generator. Here how it works

1) Make the enemy and set the attributes.
2) Make a enemy generator ....create a timer....have the generator spawn enemies
3) You now dont have to set the every enemy value.

You want an example of this then download this demo

viewtopic.php?f=6&t=9954

You learn quite a bit from that demo.

[AnarchCassius]

Actually, again, that is exactly what I am doing. The issue is that the enemy base type has descendants. The obstacle object also has descendants. All the scripts are inherited but I can't do a collision check for the base enemy type and all descendants. So I'd have to manually go over each sub-class in the script. Again with shots, either the base bullet type has to check every sub-class of enemy or vice versa.

[skydereign]

In cases of collision, you should clone actors. You can keep all your bullet types in a single actor, and just have a variable (perhaps animindex) to separate what each one should do. It's not perfect, and depending on the complexity, could be a little redundant, but hopefully less so, since the alternative is to have collision trigger for all actors, then filter out all the other actors that you don't want the collision with using an if. And as you said... that'd be rather repetitive as well.

[DST]

I encountered a similar issue when trying to make homing shots in a game where all enemies were descendants of one enemy class. My solution was this:

Copy every enemy's draw actor into a global code function. Switch the enemy type in enemy draw to run the appropriate function. Then have only one enemy type period.

When spawning them, I assign all the actions in the spawner itself. The enemy class actual has no CreateActor event.

Each animation was given the enemy name before it's modifier, and so on spawn, each enemy was given a string holding it's subclass name, and that was used for animations. The homing bullets now need only one line of draw actor code....just MoveTo enemy!

And it really didn't take that long either.

[AnarchCassius]

Well if that is how it is done. I can write in some script to handle the differences within a single actor type without much trouble. Putting all the sprites in the same actor seems a bit odd. I don't suppose it's much harder to write this way but I have to say it's a little odd for organizational purposes.

[DST]

I'll admit, it can get complicated when you're dealing with complex animation cycles. It really depends on what type of game you are making - if your enemies have to walk and run and jump and shoot, it could get complicated pretty fast.

In my case it's a shooting game, so enemies each only have one sprite sheet, and their animations occur by animpos designations inside their draw actor functions.

[AnarchCassius]

Thanks. I was gonna need such a system to switch the player's weapon anims anyway. I just got it working after looking at in examples in some of your older posts.

Thankfully my enemies are zombies and don't run for the most part and the game is top-down so I don't need a jump.