@jonSS said: I could upload it, but i dont think it can be made using KOF sprites. [...]

I do not think anyone would just use those assets in anything they released. As you said, they work well with what you are trying to teach. If you obtained them from an archive somewhere, perhaps providing a link to that location on your first BeatEmUp video on YouTube (if not allowed here), or are they one of the sets available from sites like Sprite Database or Spriter's Resource, etc.? (This presumes you do not go the Google Drive approach, of course.)

Right now godot 4 alpha keeps crashing to the desktop...

I had a problem with a desktop debug build of Godot 4 - one of the Vulkan pipeline functions crashed with a null pointer dereference after being called a few times. I used the nVidia Vulkan Beta Driver v473.11 instead of the General Release one and that problem went away. Maybe it will help you, too?

Either way, thanks much for what you have provided so far!

Peace!

To save time, I created PNG sprite sheets with transparency from the various different graphics including Ryo and StreetGuy1. The order of the sprites and the sizing is not always intuitive, but everything should work. The naming convention is SS<name><TileWidth>x<TileHeight><GridWidth>x<GridHeight>.png.

For example, SSStreetGuy1_180x180_4x7.png is the sprite sheet for StreetGuy1, and the individual tile sizes are 180x180 pixels, and there are 4 images across (X) and 7 images down (Y) in the sprite sheet. In order to make the tiling script work, I needed to add blank tiles to some of the image sets.

Here is an example of the 1Robert sprite sheet:

The files will be located here and I will update the folder with additional content as I get around to it or if anyone needs a specific sprite sheet done, please just ask and I will see what I can do.

Peace!

@Semaj31273 said: To save time, I created PNG sprite sheets with transparency from the various different graphics including Ryo and StreetGuy1. The order of the sprites and the sizing is not always intuitive, but everything should work. The naming convention is SS<name><TileWidth>x<TileHeight><GridWidth>x<GridHeight>.png.

lol, i dont know if its just good idea, the player sprites for example take about 200 or 300 images... You could be waisting time on making idividual sprite sheets...

The process is very strait foward... There are just a few things to keep in mind, to maybe keep the confusion to a minimum....

the hitBox checks all enemies / pains all enemies... When the player is grabbing the enemie he only hits(pains) one enemie... var areaOne = areaAll[0]; #----( the 1st enemie in the enemies list array [0] ).

	attacker.myOpponent = areaOne.get_owner();
	
	print(attacker.myOpponent);

3d_enemy1:[KinematicBody:2058] 3d_enemy1:[KinematicBody:2058] --- Debugging process stopped ---

[KinematicBody:2058] - this is the name of the current enemy its hiting ---> print(attacker.myOpponent);

Next in the grabBox.tscn this area looks for the grabbedBox area ( basaclly it does the same than hitBox area does to the hurtBox area )

It puts the entity ( enemie[0] ) -> [KinematicBody:2058] has the attacker opponent, so the attacker can manage only this entity the way it wants

Ive made a few extra vars that might add confusion to the code...

	attacker.myOpponent = opponent;
	attacker.myGrabOpponent = opponent;
	attacker.the_Obj_Iam_Grabbing = opponent;
	
	opponent.myOpponent = opponent;
	#opponent.myGrabOpponent = attacker;
	opponent.the_Obj_Grabbing_Me = attacker;

i was doing this for future things in case anything would go wrong the_Obj_Grabbing_Me - > this is just so that the enemy knows who is grabbing him

and in the player GRAB this is basically the same thing attacker.myOpponent = opponent; attacker.myGrabOpponent = opponent; attacker.the_Obj_Iam_Grabbing = opponent;

the player GRAB state manadges this entity the_Obj_Iam_Grabbing -> is the [KinematicBody:2058]

The player Slam state ( he grabs the enemie and trows him )

the function bindGrabEntity( entity, state, x, y, z ): in the player grabState ---> OpponentSlam = _entity;

_bindGrabEntity makes the enemy (x, y, z) the same has the player ( x, y, z )

In the player slam state

the player transforms the -> enemy Animation NODE position (x, y, z, angle ) in the function --> _slamPos( 1, -0.02, 0, -0.01, 1, 1, 0 );

it also transforms its own animation NODE in --> _animTransform( anim, -0.6, 0.55, 1, 1, 90); to take some advantage of godot flexibility, and give more costumization to the slams, withOut having edit the sprite ( rotate the image sprite and save to png for example )

Just a few things to keep in mind... Theres already some confusion added to the code mostly with vars: myOpponent myGrabOpponent the_Obj_Iam_Grabbing

You can see other examples of confusion i made... OpponentSlam --> gets its value in the "grab state" it should be the entity has decribed above [KinematicBody:2058] In the player "slam state" the function _bindGrabEntity... its using the var OpponentSlam the main problem here... is that... ryo slam has a (roll) and then a (throw) this --> roll in the slam animation attack's the enemies has it goes by... has it attacks [KinematicBody:2058] becomes the entity its being attacked...and not the entity its being grabbed... its the case for the diferent extra var (OpponentSlam)

But it should very strait foward, its an easy process the code just gets bigger and looks confusing, has more stuff ( attacks, states, slams, grabAttacks ) are added...

One simple thing to keep in mind...

for playing sounds / projectiles / dusts...effects use for example if anim.frame== 3 && nextFrame == true

this way the projectile / sound will only play / spawn ONCE Godot original animation system has signals for animationFinished() and frameChange().... but for it might keep the code scatered and more dificult to read... has it puts the code in a diferent function... This is way is more strait foward ----> if (anim.frame== 3 && nextFrame == true ):

The learning process is very strait foward It should be very simple just by doing this tutorial for example... It explains very well hitBoxes

there are also other things i didnt mentioned, like alpha values ( flash entity ) Z position... the entity.tcsn scaleY ( transform Y ) its 1.4 once it gets put on level, so it doesnt look wide... etc... but if i mention everything this post becomes an encyclopedia

Ive uploaded the game here: by making a tutorial 1st you should understand better how the code works

download link: --- ( also added the link to the 1st page ) --- godot version 3.4 https://drive.google.com/file/d/1rixJJKgw3MXySc3PV4Tt1IrprjayNZhw/view?usp=sharing

a month later

Thanks much for adding the code. Good to see others' stuff sometime to see if you can learn anything from it or maybe help them out.

Peace!

7 months later

If you don't mind me asking which part of the code control the AI Idle movement? Like example if i wanted to have the enemy AI just stand in place until the player get close which part of in the GD script that controls?