Scorpion Engine

[earok]

Back home from holiday and found a serious bug that I think nobody reported in the past couple of weeks heh (maybe they did, there's piles and piles of chat I haven't been able to read through).

Saving/Loading caused crashes, at least in some circumstances. It shouldn't do that anymore.

I was going to put on a feature freeze to get the release done, but reviewing the code after a complete break from it has highlighted some deficiencies I can maybe work on.

---

@skyzoo72 as flibble said, there's a "foreach" function under conditional that you can use to run code against every actor of a type. The simplest use of it is stuff like smart bombs that clear the screen of enemies ("foreach enemy of type myenemy do destroy_actor"), but with a little elbow grease you should be able to make it work out if there's another actor standing in the way of the current actor (though there's potentially lots of complications, you need to make sure you're not comparing one actor with it's own position for example)

An alternative that may or may not be a pain is using a kind of invisible block as a marker. That's kind of how the top down "CPU patrol" and "CPU pursuit" types avoid getting too stuck together. Basically you'd do something like:

- If an actor wants to move to the tile to the left of where it is now, check if there's any blocks of type "cpu blocker" (basically just an invisible block with no collision)
- If there isn't, place a "cpu blocker" block there, and move in that direction
- If there is, remove the block. Repeat the process from the start, but check for the right direction instead.

It's not completely foolproof but it should at least give the appearance that there's some intelligence to the AI.

[flibble42]

Maybe you could set a flag in the VARS to say which ACTOR is currently doing the comparing so it can be ignored, and then reset it after. Maybe

Create a codeblock eg Monster01

Set ACTOR type to run it every frame

Codeblock Monster01
------------------------

Set Actor_VAR1=1

Do For each LOGIC

Set Actor VAR1=0


Codeblock LOGIC
-------------------
IF ACTOR_VAR1=0 Then

*Monster logic here*

End If


Hope that makes sense.

Bob

[Lemming880]

Originally Posted by flibble42

I did try Tiled and it animated really nicely. As soon as i compiled the Map in Scorpion no animation, I can't remember the reason, so i went with blocks.

I've tested it and it works. Did you save the change to tileset.tsx after making the animation?


@acidbottle: You're welcome. I found out by chance. After trying out the backbone import function and loading the levels in Tiled I saw that one of the tiles had a film strip on it.

[Lemming880]

Welcome back Earok. I'll add another question to your pile. Is it possible to have cpu_pursuit with line of sight? So as soon as there's a solid tile in between the player and enemy, the enemy will stop pursuit and go back to normal patrol.

[flibble42]

Originally Posted by Lemming880

I've tested it and it works. Did you save the change to tileset.tsx after making the animation?


@acidbottle: You're welcome. I found out by accident. After trying out the backbone import function and loading the levels in Tiled I saw one of the tiles had a film strip on it.

Errm, Probably not.. I shall give it a go cheers.

[earok]

Latest check in solves a minor issue that propped up investigating issues discussed by Mixel and Flibble.

The "load level" codeblock had a default behaviour where it would try and set the camera position to the player's center position. But if there wasn't a player, this could potentially put the camera out of bounds (and thus mess up expressions using camera_x).


---

I probably should have an official demo with animated tiles, I only have an unofficial one (the Zelda one in the unofficial repo has animated grass).

@Lemming880 Hmm, line of sight is maybe doable using a raycast algorithm (see: https://lodev.org/cgtutor/raycasting.html ). You'd do a raycast from the enemy tile to the player tile, using block_get on each tile to see if it's solid or not (it simply returns false if there's no solid tile and no block, you may need special handling for things like coins).

You could then change the actor type to a pursuit if it can see, or a non pursuit if it can't.

That sounds like another fun thing to try and make a demo of.

[Lemming880]

Sounds tricky. I'm asking because backbone has a build in option to set an actor to 'Chasing Enemy' in combination with 'Limited Sight'. So I'm hoping for a build in solution for Scorpion too. Like a CPU_Pursuit_LOS or something. But if it can be done with codeblocks I'd be happy too.

[earok]

Finally a new experimental update (between holiday and being repeatedly unwell, I haven't had much of a chance to work on Scorpion, but I'm getting back into the swing of things).

The "control" type has essentially been rewritten. It's a fairly complex beast since it needs to take into account games with less than eight animation directions (Zelda types where you can move in eight directions but only animate in cardinal directions, also "swimming" or "jetpack" actors on Platform games that have left and right animations but not up or down ones), as well as being able to handle "smooth rotations" (games like AlarCity and Jackal require the player to smoothly rotate 360 rather than snap from one looking direction to another).

Having said all of that - hopefully it works better now on all of the needed use cases.

[acidbottle]

Great to hear you're back in the mood for Scrop

[earok]

Thanks Acidbottle !

---

Latest experimental update adds "breakpoints" to Scorpion Engine. It's not a full breakpoint debugger (no ability to step over, step through etc), but can be used to diagnose bugs in Scorpion Engine games a lot more easily.

[ Show youtube player ]

[spoUP]

Scorpion engine is a truely fantastic effort, but one thing bothers me. In every scorpion platformer i have tried, the jumps feel very floaty and slow. The easing curve feels very off compared to super mario and the likes.
It feels like it should be faster on the way up and accelerate more than it does now on the way down. It feels a bit like jumping on the moon now.

[flibble42]

I'm going to assume you are using CLASS>Player and CONTROL_PLATFORM. And you found no settings that could help, jump speed, max fall speed, gravity etc?

[Lemming880]

Originally Posted by spoUP

Scorpion engine is a truely fantastic effort, but one thing bothers me. In every scorpion platformer i have tried, the jumps feel very floaty and slow. The easing curve feels very off compared to super mario and the likes.
It feels like it should be faster on the way up and accelerate more than it does now on the way down. It feels a bit like jumping on the moon now.

Yes Scorpion is perfect for space platformers! But I know what you mean. When I started making my platformer one of my testers already mentioned that the movement is odd. I tried to adjust it but it seems like it's always more or less the same outcome. I want gravity to pull harder on the player but it still has to jump the same height and length. It's too late now because my game is mostly finished. But I adjusted the level design to the player movement so the moon jump feeling is gone for the most part.

Btw guys at lemonamiga.com, boxx 4 is not frozen, it's in constant development.

[earok]

I had a think about jump physics, and did some research on how different games handle it. Broadly speaking, platforming in Scorpion works this way:

- Jump upwards at the defined JUMP SPEED value
- While the player is moving upwards, if they release the jump key, increase the gravity (so that the jump height can be controlled)
- If the player has released the jump key, or is moving downwards, apply normal gravity

That essentially results in a perfect parabola when jumping, and I believe this is more or less the physics used in Sonic the Hedgehog (though it seems Sonic has bit more of an abrupt cut-off when releasing the jump key). But it's not the physics system used in all platformers, Mario Bros for NES and Alex Kidd for SMS basically do the opposite.

- Jump upwards at the defined JUMP SPEED value
- While the player is moving upwards, if they're still holding the jump key, apply less-than-normal gravity.
- When the player is moving downwards or has released the jump key, apply normal gravity


What this means is that in Mario and Alex Kidd, the "down" portion of the jump is far faster than the "up" portion of the jump, whereas the "up" and "down" portions of the jump essentially take the same time in Scorpion Engine.

It should be a relatively simple option to add but I'll need to dwell a little more on the best way to implement it.

[earok]

Major experimental update time!

* New "debugmode" overhauls breakpoints with the ability to step through code line-by-line while playing
* New "debugmode" also adds ability to flag variables as "watch", alerting the player whenever a variable has been changed (and which line of code was responsible)
* New movement type "control_platform_maryo" emulates a Mario Bros style platform game by reducing the usual gravity while there's upward momentum or the jump button is pressed (essentially the downward movement is always faster than the upward movement)
* New movement type "control_platform_sonyc" emulates a Sonic style platform game by maintaining a smooth parabola whether it's a small or large jump
* New movement type "control_platform_jetpack" emulates a Jetpack with upward acceleration counteracting gravity (can also be used to emulate "swimming" where a player is being dragged towards the bottom of the water, but can accelerate upwards)
* Minor fix for playing sound on repeat, prevents issues where the sound can switch unexpectedly between channels
* Fixed bug with "control_autonavigate" where the actor wasn't recognized as a player

Video about the new platformer types:

[ Show youtube player ]

Video about the new debug mode feature:

[ Show youtube player ]

[spoUP]

Wow @earok!!
Very quick update, and very nice, i like the mario one best.
Great work!

[Mixel]

Oh wow that’s a bunch to experiment with! That debug mode is absolutely crazily useful! That’s going to be so invaluable. Things are getting so much easier!

The classic type seems most like Turrican and some other games so I’ll likely keep that for cmo/Francis but Anna has always felt oddly floaty with her increased jump height so I’ll experiment with her.. very very cool, I was going to try manually adjusting the down speed when you let go of controller input(?) but I’m really not sure which type I’ll do now. The Mario one might be more suitable for Wizonk, for sure, too. And the sonic one will maybe work well on my motorbike sections. Definitely curious to see what acidbottle does with wonderboy and Dante with green beret and castlevania with these additions.

The jetpack thing is awesome I was going to try that with codeblocks too but that makes it a hell of a lot simpler.

[acidbottle]

Woah, that's an awesome and unexpected change to control types! Nice job earok, will have fun having a mess around with those

[Lemming880]

Wow earok, one moment we talk about it and the next you already made it! But it seems like things got a bit mixed up. The original Control Platform (now called Classic) works different. Gravity pulls harder when jump is released. As if it's acting like Maryo. Maryo now rockets the player into the air really high. Sonyc feels good but it doesn't feel like the way you described it, it acts more like how you described Maryo and it feel exactly the same as Classic. The Jetpack does what it says so I don't see a problem there.

Edit. After seeing the video I will experiment with the Jump Cancel and Jump Boost values and see if that works.

[earok]

Thanks all!

Did do a minor fix for the bug @Lemming880 descripted with the classic movement type.

It's all very new but the new movement types should work as demonstrated in the video. The important thing is that the jump height value should still be correct so if the mechanics of a different movement height result in a different jump height, just need to tweak the gravity and boost etc until it's back the way they were.