Scorpion Engine

[earok]

Originally Posted by saimon69

Is the 'F00 crashes everything' bug still in the music player?

I assume so - I see that you've put a question about it in the PTPlayer thread that hasn't been answered yet.

[Lemming880]

The platforms do not disappear anymore so it seems fixed.

[earok]

Great to hear


There isn't going to be an experimental update today but there should be one tomorrow. I've been working on streamlining the rather confusing setup for firing projectiles, basically upgrading the "shoot projectile" option with a few variations (merging the "shoot projectile at player" option into it as well so it's a single command). So there's:


- Shoot forward: Shoot in the direction the actor is moving (Commando)

- Shoot using projectile default: Use the projectile's default direction (1942)

- Shoot at player: Self explanatory

- Shoot if player in front: This one is a little harder to explain. Basically it's just shooting the projectile in front, but it's cancelled if the player is behind the actor. It's essentially to prevent it looking like the actor is just shooting in random directions if they're not currently facing the player.


Do let me know if you have any thoughts.

[Rochabian]

At this stage, is there a way to "lock" the shoot direction, for strafing for example ? Or is it planned ?
I dream about a top down shooter on Amiga like chaos engine where you can strafe or go backward while shooting (like a modern dual stick shooter, but locking direction with a button)

I really appreciate the hard work that went into making this game engine, seems to be user-friendly

[earok]

Originally Posted by Rochabian

At this stage, is there a way to "lock" the shoot direction, for strafing for example ? Or is it planned ?
I dream about a top down shooter on Amiga like chaos engine where you can strafe or go backward while shooting (like a modern dual stick shooter, but locking direction with a button)

I really appreciate the hard work that went into making this game engine, seems to be user-friendly

Cheers

That is indeed possible with the Strafe tickbox in the actor tab

[acidbottle]

Okies ..

on a recent experimental update, the cpu_platform actor type could no longer have an animation set to the up or down axis, so moved my anim for these to up left (or something).

I have a codeblock that detects direction player is facing and hitting the actor to trigger a suitable stumble animation. This no longer works. Since I have no idea why I used cpu_platform type, instead changed to just cpu and same result. Animation is juddering and not triggering. The animations differ on each side of actor so this is why this is done in this way.

Older version seem to trigger the anims fine.

Better way to implement a side detection of an actor? Thank you!

In addition to this, I need the player to lose energy when it stumbles on the actor, though health=health -1 seems to drain the energy bar too quick, presumably its -1 on each frame instead of the one stumble. Since I cannot use fractions for the variable, is there also a best way of handling this.

Sorry for the questions, is so close to version 1 now and know there is much wisdom on this boards

[UltraNarwhal]

Originally Posted by acidbottle

In addition to this, I need the player to lose energy when it stumbles on the actor, though health=health -1 seems to drain the energy bar too quick, presumably its -1 on each frame instead of the one stumble. Since I cannot use fractions for the variable, is there also a best way of handling this.

You could make a variable that gets set on stumble and unset after deducting 1.

Something like.
Stumble, set stumble to 1, if stumble = 1, set health to health -1, (yield x frames) set stumble to 0.

[acidbottle]

Thanks again Ultranarwhal.

I needed to lessen the number frames I was pushing the player by half also but your logic, as always, is very sound

[earok]

I would personally just increase the amount of health so it takes longer to drain completely (and edit the health bar so the max value was the new amount), but otherwise I'd do exactly the same as UltraNarwall to reduce the health on every other frame.


I don't know what you're doing in your codeblock but something like this should work in 100% of situations to work out the direction a player is facing. If it doesn't work, I'd need to investigate deeper.

if Player_LookDir== Look_Right
// is looking right
else if Player_LookDir == Look_UpRight
// is looking right
else if Player_LookDir == Look_DownRight
// is looking right
else
// must be looking left
endif


I'm assuming animation juddering means that the animation is playing repeatedly from start rather than being allowed to play to the end? Do you have anything to prevent the shove from triggering if it's already been triggered?

[acidbottle]

Thanks earok. I have no issue with the lookdir codeblock, it looks very similar to your example above and will happily trigger left/right anims as required. You are probably correct that it is juddering as the anim seems on constant repeat.

I threw in a var for stumble and this is set to true - deduct energy - yield - false, as Ultranarwhal has suggested, upon hitting the rock actor. On an older scorpion build this animation just triggers the once when hitting the rock, no issues.

Happily, however, it is now losing the correct energy amounts, or near enough the same as the arcade version.

I can complete the project with the older experimental version so is no huge issue, hope nothing too awesome happens to experimental though!

[earok]

Feel free to send through your source code, I'd really like to fix it if I can it could well be an error in the latest scorpion, in which case it really needs to be fixed before I can do a live publish.

[acidbottle]

No worries earok, thank you again. Will bundle it up and send it over later tonight to have a look at. Only started getting this issue after the platform_cpu changes so thought it may be related to that, however it is probably something entirely different related to animations or how I handled the collision in the codeblock!

[Lemming880]

So eh.. will the top bar ever be moved 1 pixel to the left?

[earok]

Check in: Shoot options for both code blocks and actors have been adjusted:

- Shoot forward: Shoot in the direction the actor is moving (Commando)

- Shoot using projectile default: Use the projectile's default direction (1942)

- Shoot at player: Self explanatory

- Shoot if player in front: This one is a little harder to explain. Basically it's just shooting the projectile in front, but it's cancelled if the player is behind the actor. It's essentially to prevent it looking like the actor is just shooting in random directions if they're not currently facing the player.


In addition, if you use "none" as the variable for shoot, it'll use whatever the actor's default projectile settings are.

---

I tried to fix the top bar issue for over two hours and made absolutely no progress, I can't fix it unless someone gives me the exact copperlist adjustments to shift a 320 pixel wide non-scrolling display by one pixel to the left (half a pixel on AGA). The main display has been painstakingly aligned such so that all of the copper bars/sprites/bitplanes are perfectly aligned with each other on both OCS and AGA which puts it out of alignment with above and below copperlists.

[Lemming880]

Ouch I didn't expect it would be such a challenge to move the bar by 1 pixel. Well thanks for trying and hopefully someone will give a solution. For me it's no problem to just draw the bar 1 pixel to the left. And since the play field is only 256px, I don't think anyone draws wider panels than that anyway so you have room to move it.

[domkid]

hey guys, just to let you know that Maria Renard's Revenge is on standby, for the Wip on Rick Dangerous for AmigameJam with Troudki (Z-Team).
[ Show youtube player ]

[Mixel]

I aligned my top/bottom bars by eye so had no idea they were out of alignment with anything?

Great demo domkid, that looks like it’s coming along really well!

@earok ooh! That’s great about shoot directions.. tbh I have quite a lot of logic making sure things turn before firing at you, or don’t fire unless you’re in front of them..
Is it like a cone (so if you’re right of them it fires if you’re Right, Up_right and Down_right, or is it more precise than that?

[earok]

@lemming880 it should be such a simple thing, I'm not quite sure why I couldn't manage it.


@Mixel It uses the same logic as CPU_Pursuit_Direct to work out the player's direction. There's also special logic to handle the case of the player standing diagonal to an enemy that can't normally move diagonally (because they don't have diagonal animations set etc)


------


Latest update:

- Can trigger an actor's attack sound in codeblocks
- Can trigger an actor's jump sound in codeblocks
- Triggering an animation that's already playing won't force the animation to play from scratch (which I figured is what people wanted 99% of the time)
- However, if you really do want to force an animation to replay from the start, you can now cancel the current animation with a new trigger in Set Animation (which resets the animation to the actor's last idle/walking animation).

[earok]

Second daily update - was inspired to make some further changes and I think people will like them (I hope!)



In the gif:

- The Anhk is set to the new "camera locked" movement type, should be useful for UI elements. Use var4/var5 to set the x/y offset from the camera.

- The second green guy is the new "parent locked" movement type. Parent locked is fixed to the position of the actor that spawned or shot it, and also copies the animation direction - should be useful for things like wingmen in games like 1942, and splitting the legs from the torso in other games.

Again, use var4/var5 to set the offset.

It's not extensively tested so there might be some weirdness when actors are recycled and such.

[Neil79]

Originally Posted by domkid

hey guys, just to let you know that Maria Renard's Revenge is on standby, for the Wip on Rick Dangerous for AmigameJam with Troudki (Z-Team).

Featured on IndieRetroNews