Inheritance - Start using it!

[DST]

It takes a long time to learn the ins and outs of ge.

Only recently have i begun to understand inheritance, and omg, i wish i'd known it from the start! This needs to be added to the wiki page (which is becoming a necessity more and more each day especially after this morning's bad spam post) and also to the inprogram tutorials.

INHERITANCE allows you to automate events for actors, it also automates the collision detection for those actors. So you don't have to write a 'collision>any side>playershot>' for each enemy anymore; just do it once!

This is SOOOOO simple!



Create an actor called enemy.
Give enemy actor 2 integer actor variables.

health
state

set state to 0 on createactor and health to whatever.

now on Collision>any side>playershot)
DO NOT PUT ACTUAL EFFECTS HERE! (No animpos/response stuff!!!!!!)

Setup your two variables instead!!!

Code: Select all

{
state=1;
health-=collide.damage;
if(health<=0){
state=2;
}

Now add your first enemy. Lets say its green slime. On the inherit events from on the actor tab, choose enemy.

Now in green slime>draw Actor>

Code: Select all

switch(state){
case 0:
//do your alives stuff here;
break;
case 1:
//do your getting hurt stuff here!, and a timer that resets state to 0.
break;
case 2:
//do your dying stuff here!
break;
}

Now start the game, and shoot it! It responds to the shot, even though slime has no collision of its own, it inherits from enemy.


That's how you make games! (Now why did i have to use GE for three years before i learned this? Let's do the wiki, everybody!)



Now go forth, and make excellent games!!!!!!!!!!

[pyrometal]

Sorry DST, I have to pos a few objections... I hope you won't hate me too much after this blurb. Well, inheritance certainly is useful, but it also suffers from serious disadvantages too. I will state and explain these:

Firstly, an actor will inherit ALL of the events/actions of its parent. This is good if the actor inherited from is a really basic "template actor", as you can save a lot of copy/pasting efforts, especially when it comes to create/destroy actor routines which are ALWAYS the same for ALL inheritors. This last part is the problem with using inheritance... Let's say you create a slime enemy and its health is set to 1 by the create actor event of the template actor it inherited from, this enemy will take one hit and die right away. Now, if you wanted to create a second enemy, let's say a bear, and you want it to have 5 health points instead of 1, your stuck between a few choices:

-(1) either you make a new "create actor" script in the bear actor which resets the health value from 1 to 5 and hope that the later script is executed last so the hp value is overwritten to 5 (error prone + inefficient, if the opposite happens, hp will still be 1);

- or (2), you create cumbersome actor type checking within the template actor to see which type of enemy is being created and set hp accordingly (inefficient);

- or (3), you don't use inheritance and copy/paste a modified version of what you needed inside the template.

Now, if an actor had been able to inherit selectively and exclude the incompatible sections to include its own, inheritance would have been fine in this example, but unfortuantely it cannot... DST, you have found a good type of 'work around' to the problem I must admit, but it will cause almost every event to set some kind of flag to be used inside of the draw actor event, which may end up being more effort than simply having copy/pasted code in the first place and not so different from having the code in their respective events in the first place... Also there still is a risk of encountering the previously stated issue as well.

Another thing is actors are not capable of "multiple inheritance" which is inheriting from multiple actors, furthermore restricting the of GEs inheritance system (Research this concept on your own time if you need more info about this). You could, but you would need to create an 'inheritance chain' system, which, of its own will require a lot of maintenance...

The end state is that inheritance in GE is too restricted to be used effectively in most senarios... However, I will admit it can save loads of time if you have many actors that must behave in the exact same manner. The best use is if you want to use one set of game mechanics, but also want to have sprite selectability (skin selection). All the inheriting actors can then contain nothing but their own sprites and behave exactly the same as the actor they inherited from. Other than this, I wouldn't see too many other good ways to use it unless improved in the future.

Feel free to counter argue or ask me to clarify. I know this is a lot of text to go through, and I may have missed details in my explainations. That's all I have to say! ttyl DST, I'll be awaiting your reply.

--pyro

[DST]

-(1) either you make a new "create actor" script in the bear actor which resets the health value from 1 to 5 and hope that the later script is executed last so the hp value is overwritten to 5 (error prone + inefficient, if the opposite happens, hp will still be 1);

I wouldn't use that method.

- or (3), you don't use inheritance and copy/paste a modified version of what you needed inside the template.

The purpose of the inheritance is twofold; One purpose is to make editing easier (not having to update scripts at several locations to change a game aspect). So i would avoid duplicating script whenever possible. The draw actor does not inherit as long as you have a separate draw actor for each enemy; which of course you would, because you want them to act uniquely and individually.

- or (2), you create cumbersome actor type checking within the template actor to see which type of enemy is being created and set hp accordingly (inefficient);

This method would be simplest, if you remove the 'cumbersome' part.

1. Spawner creates enemies specifying the animation. The enemy will continue with this animation, as it is a complete spritesheet and is animated using variables in draw actor.

2. Enemy>CreateActor>

Code: Select all

health=ehealth;
speed=espeed;
animpos=type;

3. The spawner (there is only one for the whole game) simply switches its variable 'monstertype' and sets the appropriate evariables when the monsterswitch rolls around. (so the cumbersome type checking only happens <20 times in one level).

...but it will cause almost every event to set some kind of flag to be used inside of the draw actor event, which may end up being more effort than simply having copy/pasted code in the first place

Enemies have very different draw actor scripts. They all use the same set of actor variables, which makes scripting them easier each time. I want the enemies to pop, and be unique!

The draw actor variable timeline makes a lot of sense. Its just like making a movie! Look at it this way:

Cycle start -----100fms -------130fms ------------------------- 320 fms
-----------------VarA Event
----------------------------------VarB Event
----------------------------------------------------------------------VarC Event

Code: Select all

checkvar++;
if(checkvar==10){

vara++;
if(vara==100){
vara=0;
//perform action;

varb++;
if(varb==130){
vara=101;//now the vara event is disabled
varb=0;
//do this;
}

varc++;
if(varc==320){
vara=0;//turn vara back on
//perform action;
varc=0;
}

checkvar=0;
}



The entire script is only being run every 10th frame. I used a common factor of all the 'flag times' that i set.

This is actually very simple code, especially considering that there are only going to be 20 of these actors on screen at maximum, and only about 4 for the majority of the game.

Objects like bullets and fx are more numerous, but have even smaller scripts.

spark>draw actor>

Code: Select all

transp+=.03;
if(transp==1){
DestroyActor("Event Actor");
}

The other purpose of inheritance is to simplify the computations. It is better to have an actor with a specific set of rules that acts on them; You don't want it making unecessary decisions on the fly.

So what a spawning script is , really, is taking the stored rules of the game, and outputting the slimmest possible object and inserting it into the game. If the game is calling for ninjas, we make ninjas. The ninjas do not know about samurai, they only know how to do ninja stuff.

When i make a shot, it simply uses creator.espread as its angle and creator.espeed as its speed. Referring to creator is one of the nice features of GE; its another way to use inheritance.



The final result of this is that i can inherit the basic behaviours so i don't have to rescript them each time; what i script each time is unique behaviour.

This results in the ability to take image directly out of graphics software, into ge, and immediately see your new enemy unit in action, which speeds up the creation process my many orders of magnitude.

There are many ways to success; as a design-oriented person, i look to create a space needle.

That is, if you wanted to set a guinness book of world records building height record, you don't need to build the massive world trade center type buildings. You can build a space needle building, and be competetive with only a tiny fraction of the resources. So tweaking the game and polishing it can make even the crappiest script shine.

Speed is of the essence. Without speed you won't be able to polish something to make it truly an EXPERIENCE for the end user. A GIFT to the user. Like a musician would.

[makslane]

INHERITANCE allows you to automate events for actors, it also automates the collision detection for those actors. So you don't have to write a 'collision>any side>playershot>' for each enemy anymore; just do it once!

Exactly

[DST]

That's what i said when i understood it. Exactly. This is what makslane intended.

If we could use ge the way it was intended, i think, we wouldn't care about things like copy/paste script or in editor menus because its designed for someone that knows how to use it.

To this end, i'd say its the challenge of any game creation software to cater to its audience; if you make it for n00bs, then you have to work to bridge the gap between your programmer knowledge, and their windows icon clicking computer experience.

However, to a great extent, this is the allure of ge; it is an enigma to be decoded. It's raw nature forces you to understand better game structure; you can't just ctrl+z your way out of situations.

As i've said before, ge is probably my favorite game ever. The primary motivation for using it is fun.

[pyrometal]

This is all good, but I still think there is much to improve to make GE's inheritance fully versatile. If the things I mentioned in my previous post one day get fixed, then I will definetly use inheritance as well, but until then, I personnally have little uses for it, except the ones I've mentioned... To the public out there, try out GE's inheritance feature for sure, its really cool, maybe you'll find good places to use it that I'm not thinking of. I think both sides of the fence have been well enough debated, so this should be my last post in the topic. ttyl all!

[makslane]

One more info, the Event Inheritance is overridable, so, if you have an event in the base actor, (like a Mouse Down->Left) and define the same event in the actor that will inherit the events from the base actor, the event in that actor will be used, instead the inherited event from base actor

[pyrometal]

I didn't know that! This is VERY good then, it increases my perceived versatility of inheritance by quite a bit! lol, I almost feel like converting my earlier blurb a bit now as I made the assumption there was no way to overide anything... But I won't, I did make this mistake after all and erasing parts of the post would show I cannot admit defeat.

DST, I delare you the winner of this argument! Well done!

[DST]

It takes a long time to learn the ins and outs of ge.
Now why did i have to use GE for three years before i learned this? Let's do the wiki, everybody!

You're not the only one

[Kalladdolf]

This has been very helpful, thank you guys, makslane especially (with the overwriting thing).
I think I've heard it somewhere before but I wasn't sure. And after mis-using it couple of times and therefore having loads of bugs in my game, I quitted using it at all.
Now, I am going to re-use it again, it will certainly be more help for bigger games.

So, practically, when you want your actor to inherit certain events and not the others, you select the ones you don't want, go on script editor and enter something like this:

Code: Select all

();

That how you do it?

[zygoth]

Yes. I have used inheritance since my very first game and it can save a whole lot of time. I made a baseenemy that all my enemies inherited--it had scripts for dying, getting hit, etc. It is very helpful.

[Bee-Ant]

Just like Pyro has mentioned...it has a good and bad points...
I have never use it since it doesnt fit my game