megatronx

I don't think that's possible with the sources from your link. These depends on node.js, because of that it's not possible to import the scripts as javascrpt-files in Construct2. To make it more difficult there are dependencies to binary-files, otherwise it would maybe possible to make one javascript-file without dependencies from node.js.

My wild guess:

I guess your game has a very low resolution, like 320*200. The monitor/display you are using has full HD or higher. With pixel rounding the pixels jumping for example from the original x-position 100 to 101, but HD has a 6 times higher resolution. So on your display the pixel is not jumping 1 pixel but 6 pixels and this is notable.

You could try to put scan lines over the layer or some kind of scaling filter, but shaders can use a lot of fill rate and make your game unplayable on mobil.

kiugetski

In C2 the SetColor Effect has 3 parameters R, G and B. In C3 it has only 1 parameter. You have to use the rgb-command with the same 3 parameters as values.

In C2 it looks like that:

Parameter 0 has the value: 255 - (smiley.HP / smiley.MaxHP * 255) that is your R(ed) value.

Parameter 1 has the value: smiley.HP / smiley.MaxHP * 150 that is your G(reen) value.

Parameter 2 has the value: 0 You don't set any B(lue) value.

In C3 there is only one parameter for SetColor but that expects a rgb-value rgb(R,G,B). So you have to set the parameters from C2 as values in the rgb-command:

rgb (255 - (smiley.HP / smiley.MaxHP * 255), smiley.HP / smiley.MaxHP * 150, 0)

In C3 it looks now like this:

The example as c3p:

https://drive.google.com/uc?export=down ... llZSGlEVTQ

and i know that c3 now use rgb(255,255,255)

As you said, C3 using for setcolor only one parameter with rgb-values.

So you have to replace the two events 'set effect 'SetColor' parameter 0' and 'set effect 'SetColor' parameter 1' in C2

with one event in C3:

Set effect SetColor parameter 0 to rgb (255 - (smiley.HP / smiley.MaxHP * 255),smiley.HP / smiley.MaxHP * 150,0)

That's only the paramter 0 and parameter 1 from C2 on position 0 and 1 in the RGB-Value, position 2 is like the parameter 2 in C2 still zero.

Matei511 only objects with the physic-behavior are solid to each other. The solid behavior as no effect to objects with physic-behavior.

First, don't mix solid with the physic-behavior that can cause sideeffects.

You don't have to move the objects yourself, the physic-behavior will do that for you.

Set in the Physic-Properties immovable to yes for platform_1 and no for sprite5.

Change the 10. event to:

lever_1| Is active - > platform_1| Set Physics Movable
                       lever_1| set animation frame to 1[/code:2nxsyxi1]

Now it should work.

Description here:

behavior-simple-enemy-ai-update-was-ghost-ai_t193244

This is the C3-Version. It's only a test, so be very careful if you use it.

Until further notice no C3 support.

https://drive.google.com/uc?export=down ... mdyd0JNbFE

Try the first beta.

Link in first posting.

So you mean that they actually follow the tiles and not going around them?

Exactly, you made a path out of tiles and the enemy will follow this path on the tiles. Independent of where the target of the enemy is, it will always follow the target on the tiles. If the enemy is not on a tile it won't move.

[quote:29svw7mh]So, maybe if I have a layout full of static objects, I will be able to generate an invisible functional tilemap that will erase all the tiles at object positions? Will that work?

I don't know if I understand this question correct.

If you would fill a complete tilemap with tiles and only delete on the position of the obstacles the tiles it should work. But the enemies would turn only in 90° steps. So it would look a litte silly and I don't know if there are other side-effects.

Maybe I do a 'Pro'-version with 45° degree steps and more individual settings, but at the moment I would be happy if I get this behavior to work.

[quote:1pcb7v97]Will it be able to detect sprites as obstacles or is it only for tilemap?

At the moment there is no detection of sprites or obstacles. You have to make a tilemap with tiles as a path for the sprites and they will only move on this path depending on the mode you have chosen.

Here is the tilemap from the PacMan-Example. This are all transparent tiles. The red boxes are only the collision polygon.

So you can simply make a tilemap with transparent tiles and put it above your game. That the enemies behave more or less intelligent also depends how good you chose the path not only one the Behavior-plugin.

Thanks,

I recognize that the name is a little bit misleading- This behavior will not only for a PacMan-Game. It should work for all maze like games where you can build a closed path with a tilemap and enemies who chases you.

It has not even a top down game. A game with a side view, what has ladders or something like that would do also work.

Update:

I changed the name to 'Simple Enemy AI'. I think that is more appropriate.

Description:

A behavior with 6 different modes for chasing or following a target. It based on the 4 different Ghosts of PacMan, so it's a very simple AI. There are only a few things you can adjust.

Enable or Disable the behavior.

There are no stop or move actions, you have to use 'set enable' as an action.

Speed

How many pixels in one second the object moves.

reset direction

This is only an action. Normally the sprite (enemy) would never move backwards. The only exception is if it stuck on a dead end. This should avoid that the enemy is jitter from one direction to another.

With reset direction you can force to recalculate the directions inclusive backwards. This can be helpful if your enemy should flee for something (like the PacMan Ghost when PacMan gets a pill). It could be very bad if the enemy have to move to the next cross-way , before change the direction.

get direction

The direction the sprite is moving at this moment.

1= up; 2=right; 3=down; 4=left;

Helpful for the animation of the sprite.

getpx, getpy are for debug ignore them.

chasing mode

For each chasing modes you have to set different links to other objects. This are all actions that you should put in 'On start of Layout'.

All need a Tilemap with a path of tiles to follow. It's up to you how the path looks and the size of the tiles, but this has a big influence of how good the AI works. The tiles have not to be transparent or on the top layer. You can also put the layer as bottom layer. There is no need that this layer is visible at runtime. If you put at at the bottom this could have a positive effect to the performance if you have a really high resolution and a big tilemap.

The other objects are all sprites:

Target - The one that should be attacked.

Hideoutt - It's like the second Target, but more for retreat.

Cohunter - It's only needed for the encircling mode, best is to use a sprite with the follow mode.

I recommend to use not an instance of the main enemy sprite but rather a new sprite-object.

It will only choose the first instance of objects, so it could be possible that the cohunter is the same instance like the main hunter (enemy).

The modes are:

retreat and follow

This are practical the same.The enemy follows direct their target. The difference is that you can give each mode a different target, then you can switch targets at runtime. You could do the same if you switch the target in one of the modes at runtime. It's up to you how you do that.

Needs:

A Tilemap and a Target.

ambush

Tries to get in front of the target.

Needs:

A Tilemap and a Target.

encircle

Needs a second sprite as a 2nd hunter and tries to encircle the target.

Needs:

A Tilemap, a Target and CoHunter.

shy away

Will follow the target, but if it get too near (6 tiles in every direction) it will flee to his second target.

Needs:

A Tilemap, a Target and hideout.

guard

The opposite of 'shy away'. Guards a target by circling around it. If an sprite comes too near (6 tiles in every direction) it will attack this sprite as long as the sprite is in 6 tiles range.

This behavior allows only 90° turns.

If you forget to link a needed object for the mode the sprite won't move.

This is a first beta. It's highly possible that this behavior causes crashes. So be very careful and don't use it in big projects. It's more for testing at the moment.

In the example you can see how to use the behavior.

Put the behavior (only 'simpleenemyai') in: Program Files\Construct 2\exporters\html5\behaviors

https://drive.google.com/uc?export=down ... 0pJWUstaGs

obsolet:

A behavior with the 4 AIs of the 4 different Ghosts of PacMan: Blinky (red), Pinky(pink), Inky(light blue/turquois), and Clyde (brown).

It uses a tilemap as path for chasing a target. Each Ghost has a different way to chase his target.

Blinky:

Chases his target direct.

Pinky:

Tries to perform an ambush.

Inky:

Inky uses Blinky to encircle his target.

Clyde:

Chases his target like Blinky. If he comes to close to his targets, he flees.

This based all on the work of Toru Iwatani in 1980. It's not really an AI. All Ghost have more or less a simple behavior to chase PacMan. So it looked more like chaos than really an intelligent chase. The advantage is the very low cpu usage.

A made a little demo to show how the ghost are chasing PacMan. PacMan hasn't really an intelligent behavior. This will only show how the ghost chases. So no collision detection is implemented.

https://www.scirra.com/arcade/other-gam ... test-19126

At the moment it's in a very early stage, so no download link. If is there any interest in this behavior I will made a usable version.