Well, I knew Construct 2 was in development in some form due to talk on the IRC channel, and the Sourceforge page, but still...

Well, I'm looking forward to testing C2 out myself soon enough!

Actually, I think I have an idea...

* Use a larger set of nodes to automatically generate the 'routes' that the AI can take, taking into account platforms and level layout.

* Use the Infinite Mario AI technique of "close nodes" for short-term decisions, like avoiding projectiles or enemies. Thankfully, the Mario AI code is open-source, so anyone can check it out and figure out how it works.

newt: One of the images here gives a rather useful idea of how A* works, well, for Mario, anyway. Basically, A* uses points, or 'nodes' to determine where an AI object should go in each tick, in order to get to a goal in the shortest possible distance. If there is an obstacle where certain nodes are, the AI will ignore them and consider other nodes instead.

Using the third image in the link I provided, the first slide shows a rather basic bunch of nodes (there are generally a lot more of them), representing certain actions Mario can take, like jump to the left, go to the right while speeding up, and so on. It will pick the best option first (in this case, going to the right fast, since the goal is the end of the level), but when this is evaluated, in the third slide, there is an enemy on that node, so the AI 'backtracks', declares that node a no-go, and then picks the next-best node - jumping over the enemy while also speeding up. The AI will then pick the next best node after that, and so on.

Well, I enabled scripting in my cap, which... ALSO causes causes crashing between layouts, except different ones this time.

Now that I think about it, this bug's been around for ages, hasn't it?

And I inadvertently suggested this sort of plugin in the Platforming AI topic, haha.

Anyway. The RTS movement is based on A*, stick an obstacle with the 'solid' attribute in the middle of the "RTS Basics" template and the units will automatically move around it, as well as any other RTS units. However, I think this might be difficult to utilise for a platformer, since it's an RTS Behaviour, so, someone could well possibly use the code on the SVN as a base for a platformer pathfinding behaviour.

Make it compatible with the Custom Movement as well, plz.

Edit: Ah, what the heck. I might as well set up a 'design' for how such a plugin could work and what it could do.

Needed Functions

• Identifying solids and platforms that the AI can land on, and working out routes to take to a destination based on the environment using nodes. The AI should also be able to drop through platforms, if it can't do this, it will find another route.
• Using objects, families and attributes to identify objects that the AI should actively avoid, which creates nodes with each tick. Of course, the event should also be able to set the 'margin for error' to allow the AI to 'make mistakes', since it would be no fun if the AI, say, could perfectly avoided every attack you throw at them.
• Being able to set a 'target' to chase after, and how much distance to stay from said target (for example, you could set the current position of the mouse as the target ). Or set a destination via events.
• In general, being able to set the 'behaviour' of the AI in how it gets to a destination. The AI can try and get to its destination as fast as possible either while being as careful as possible or being downright suicidal about it, or the AI can take it slowly and more carefully. Or just as suicidally. Your choice.
• The AI could be given a certain 'task' if there is no active destination or target. For example, the AI can wander within a certain range, or just wander aimlessly.

With Platform Behaviour

• If the same object has the Platformer Behaviour, the AI will use the behaviour's variables, eg, speed, jumping strength, etc.
• Not much else here, really, the AI uses the behaviour to move around.

With Custom Movement Behaviour

• Since, obviously, the Custom Movement's stuff is done in events, if the object has the behaviour, the AI will take values defined by events (variables are recommended) in place of the variables used by the Platformer Behaviour.
• The controls, such as moving around, jump, etc. Are also handed by events. In order for this to work, the Function plugin is required. The developer just needs to identify to the AI what the controls are, and what Functions are tied to them, and if a function is not being called while the AI is holding a 'virtual key' down, the AI will stop hold the 'virtual key', and try pressing it again.

Optional Functions

• The AI can be 'made aware' of additional abilities that it can perform in order to gain greater speed or horizontal/vertical distance, using functions and controls. These additional abilities would need: ** Maximum Distance/Speed gained ** A 'Priority' value, as to how often the ability should be used in certain situations.
• The AI can use certain functions/controls to identify attacks that it can perform, similar to additional abilities, but in a certain distance from an identified target, and if certain conditions are met. Such events would require: ** Minimum recommended distance from the target (the AI will either ignore or note this value depending on its behaviour) ** Maximum distance from the target ** A 'Priority' value, as to how often the attack should be used over other attacks.

Well, that's all I've got for now, but I might update this later.

Edit: Holy crap, it only just occured to me how OLD this thread was. However, I believe gravedigging topics is fine as long as the poster brings in something meaningful.

The way I see it, you could use two possible techniques for achieving a proper path-finding result:

1) A*. A*/A-Star is a very, very effective algorithm. The RTS plugin uses A*, so it MIGHT be possible to use said plugin to determine path-finding and how the AI will respond to the environment around them. I'd imagine it could take a bit of work, however.

2) Cheat. I've Google-searched platformer AI, and I noticed this particular thread, and a few of the guys there are encouraging techniques that make the AI look smarter than it really is, eg, using additional objects that the AI uses as information about the environment around them.

Basically, it depends on how you want to go about it. However, an A* path-finding behaviour for platformers certainly would come very much in handy, might wanna keep it separate from the platform behaviour, though, in case someone (like me) is using the Custom Movement Behaviour instead.

[quote:2aorwdoc]

EDIT:

Also, it seems that the GUI objects all render in front of everything else. I added a sprite, and the sprite was hidden by the GUI, even when I put the sprite on a layer above the GUI. I don't know if this is fixable, but this was one of the main complaints about the Windows control objects.

Ok, that's not good at all. If I can't resolve this, my plugin is useless...

I believe that should be your first priority. GO GO GO.

THIS IS AWESOME.

Seriously, it's totally sweet. I love this thing. I really wanna see it fully developed, it could certainly be a very, very handy plugin.

HOLY HELL YES. <3

Honestly, it's making me wonder whether maybe this could let me just use arrays rather than 'S'... Then again, I'm not sure. A visual editor for 'S' arrays and Supers would be awesome, though.

Sweet Jesus, this is the closest thing there is to a Database editor in Construct. Man.

It certainly would help if the interface was more like, say, Excel, such as scrolling and being able to set column width/height. Also, there's a bit of a problem - the amount of characters you can input is limited to the size of the actual cell at the time.

Holy crap I think I did it.

Basically, I shoved an action into the "On Step" event at the beginning of "Basic Movement" that adds "PlayerSprite.Value('SlopeFactor')*sin(PlayerSprite.Angle-90)" to the player's horizontal speed on every step, with the Orientation being PlayerSprite-90.

At FIRST, I thought I was doing it wrong, but I experimented with the value of SlopeFactor. 0.125 obviously does nothing. However, any value over 10 is right out, as it basically turns every slope into frictionless surfaces. 1.25 DID have a slightly noticeable effect, so I doubled it to 2.50, and comparing with the MMF version of Sonic Worlds, I discovered that Sonic's new slope speed was very close to the MMF version, not perfect, but very close. Thanks for the help, guys!

All I need to do now, basically, is adjust the SlopeFactor when Sonic is rolling, so I can finally implement rolling acceleration properly. This should be fairly-

[quote:17r45vmu]When Sonic is rolling uphill (the sign of Gsp is not equal to the sign of sin(angle)), slp is 0.078125 ($001E). When Sonic is rolling downhill (the sign of Gsp is equal to the sign of sin(angle)), slp is 0.3125 ($0050).

... Goddamnit. This is gonna be a tad tricky... Actually, on second thoughts, maybe moving the decimal point to the side by one and then doubling the resulting value would work...

Uphill = 0.078125 * 10 * 2 = 1.5625

Downhill = 0.3125 * 10 * 2 = 6.25

Holy crap it worked. I have proper rolling momentum. AWESOME.

Well, 0.125 * 0.5 * 9600 = 600. Adding 600px per step doesn't make sense, agreed. But all those tiny values let me assume, the developers normalized them. Do you know, how many steps per second where used and what display size was used? I ask, because that 0.046875 makes sense somehow. For example, if the steps per second were 30 and the display width was 640, then 30/640 = 0.046875, or, if the steps were 15 and the width was 320, then 15/320 = 0.046875 I don't think this is coincidental.

But I have no clue how they would use such a ratio...

Well, I'm not sure how many steps per second, the guide doesn't specify. But I believe it assumes the resolution is roughly 320x240, as the Genesis had a maximum resolution of 320?480. On the other hand, we're not working with Genesis hardware, so the number of steps and the screen size should be completely irrelevant, methinks... Which makes me still wonder how to apply pretty much any variable listed in the physics guide, really.

[quote:wwyf7ssh]Yes, either that or the logic should be adapted. I read something about converting the ground speed to x- and y-speed:

Xsp = Gsp*cos(angle);

Ysp = Gsp*-sin(angle);

If you would take it that way without adding (or substracting) 180 from angle, then the directions are inverted. Think of the 30? example. sin(30) = 0.5, but Gsp * -0.5 would get negative, so Sonic's Y position would lower (= he would walk upwards) while he should walk downwards. You may either do

Ysp = Gsp * sin(angle) or Ysp = Gsp * -sin(angle + 180)

but stick to one method throughout the game code, and make sure the angle you pass to the object's angle is a value in the range [0, 360]

EDIT: Just to stress that. The original is based on counter clockwise. That means you may only correct on the Y-axis, not on the X-axis!

Hmm... I'm not sure messing about with the X and Y speeds would do any good, looking at the base movement for the engine. The player's basic movement is based on an On Step thing reliant on two sensors, which automatically adjusts the player's angle and the direction of his horizontal speed. Unless I'm mistaken and changing the Y speed would be perfectly fine in this instance...

Okay, I think I get where you're coming from. Still...

The ratio business is, well, rather tricky. You see, the original acceleration wasn't even close to 100. It was 0.046875. Which means the ratio would have to be literally 9600. XD Yeah, the values for variables in the guide are freaking TINY. The slope factor is bigger than the acceleration!

Also, with angles, I guess all I have to do is just add 180 onto every angle calculation or something?