Scorpion Engine

[Mixel]

Originally Posted by Z-TEAM

We continue to implement Rick Dangerous and we remain a bit stuck on a use case. We spawn bonus actors (gold inca) after loading a level, as soon as the object is captured it disappears but we don't understand how to not respawn it when the player starts the level again.

Does anyone have this kind of mechanics in their game. Spawn actor once only even reloading the level until the game is over.

that looks great again!

I do, but the way around it in my case is a bit different to what you're doing, as in most cases my levels don't start you right at the beginning (but some do) In your case you probably want to have an onspawn event on the inca actor that destroyactor's it if you've previously picked it up, measured with a custom variable? (hopefully that destroys it before you ever see it? If not you could make an invisible block, or actor that spawns the gold inca only if you haven't picked it up)

[earok]

I made some progress but ran into various bugs with screen widths and such. It looks like there won't be a 320X non scrolling version after all, *but* there will be a 304 wide scrolling version (no parallax), with 288 wide as the widest screen supporting parallax (192 as the narrowest screen, I figure no one wants or needs that but it'll be available!).

I'll aim for a tomorrow release.

---

@Z-Team Is there any reason why you need to restart the level at all? On death, you could (for example) fade out, respawn the character at the checkpoint, and fade back in.

[UltraNarwhal]

Originally Posted by Z-TEAM

Does anyone have this kind of mechanics in their game. Spawn actor once only even reloading the level until the game is over.

Yes I use this in Duckstroma for Keys/Disks. I do what Earok just said, because I didn't want the player to wait while the whole level reloaded (not that that's a problem now).

[Mixel]

Did something change about how persistent actor_vars are? I have some fast moving enemies that run off screen and back on but every time it seems like Actor_var1 is getting reset to its default, which makes for some tough enemies, haha. I've set them to never respawn and they seem to keep the var1.. Maybe it was always like this ive just never had an enemy with this behaviour to notice it with.

[earok]

@mixel I just checked and, at a glance, it does appear to be the engine's fault. I'll fix in the next upload.

@zteam I realise that there's probably enemies and such that you *do* want to resurrect. If that's the case, something like this would probably work:

- Set the enemy's recycle mode to "respawn"
- Fade out
- Destroy all enemies (use condition foreach etc)
- Fade in

Hopefully that should bring them back.

[earok]

Fairly substantial update to experimental:

- Broke the screen modes drop down into separate selectors for width, left offset and fetch mode.
- Screen modes from 192 wide through to 304 wide (288 is the widest supporting parallax, 304 might have a few glitches here and there and I'd strongly recommend avoiding copper skies and having index 0 set as black if you use that width)
- Ability to use AGA FMode3 (which restricts the screen modes you can use but gives a minor performance boost over FMode1)
- Ability to resize the height of the buffer to conserve chipram. The default is 17 tiles which should be enough for 8 way scrolling games. 15 should be fine if your game scrolls only horizontally, and you should be able to reduce it more if you use a lower YRes setting.
- Attempted fixes for VAR persistence, hopefully it's OK now!

[Mixel]

Wow that seems amazingly in depth and excellent! Ahh!

Var persistence seems still wonky, just maybe slightly differently wonky? I have enemies dying after one punch that should take 5, and some that just explodes randomly - because of my monster cleanup routine - but that's only supposed to kick in when something has 0 health.. Is it pulling actor var_1 a different actor?

I've checked in a demo with big furry beast things.. if they come on screen, then leave the screen, then come back on the screen, they only take one punch. if you keep them on the screen you can whittle them down as intended.

(i only recently started using the var options in the actor window - i used to use onspawn codeblocks, if that's relevent)

--
To get the seam to appear where it used to i have to set the buffer height to 18.. Not a problem, but just in case anyone else has a lot of parallax stuff going on built around seams being in exact places.

[UltraNarwhal]

Originally Posted by earok

- Attempted fixes for VAR persistence, hopefully it's OK now!

I don't remember persistence working previously, I got used to enemies resetting their health upon leaving screen

Anyway testing persistence does almost work now. If you kill an enemy, walk off screen and then kill an enemy of the same type it'll die instantly though (sharing old variable value?).
I put an example on my git. Kill one rabbit (2 jump hits), walk off screen and return and jump on other rabbit.

[amigaosx]

@earok
feature request:
I don't know if it possible, but it would be of great help to have a little message with a description of the tools in the engine, not sure if I explain myself.
I mean like when you hoover with the mouse over certain tool, a little flag/message appears describing briefly what it's for.

Just a thought! Thanks earok!

[saimon69]

Originally Posted by amigaosx

@earok
feature request:
I don't know if it possible, but it would be of great help to have a little message with a description of the tools in the engine, not sure if I explain myself.
I mean like when you hoover with the mouse over certain tool, a little flag/message appears describing briefly what it's for.

Just a thought! Thanks earok!

I think he refers to a tooltip or, maybe with a Help option, a baloon help like the old Mac OS 7

[amigaosx]

Originally Posted by saimon69

I think he refers to a tooltip or, maybe with a Help option, a baloon help like the old Mac OS 7

Yes, something like that. I've attached a quick mockup, although in this example it seems obvious what the option does. For example 'Multiplexes' I'm not sure what it is for.

[malko]

^ could be nice to have in a second time. Later...

[Mixel]

Tooltips etc are a good idea but explaining a complex concept in a tooltip can be really difficult. Even with the posts explaining multiplexing in this thread, it’s still really confusing, with a lot of palette considerations etc. They’re mostly relevant for vertically moving onlysprites.. (and totally irrelevant for bobs)

http://eab.abime.net/showthread.php?...ex#post1503919 Multiplexing discussion starts there.

Eventually a little (?) button next to each section taking you to a guide would be what makes sense imo, but it’s changing sooo quickly.

[Mixel]

Lol posted in the wrong thread there for a minute…

Feature request: “substitute animation” in codeblocks.. so all instances of a certain animation are replaced by a specified other animation, until you tell it otherwise? (Even tricking any player_anim checks)

Would be useful for things like invulnerability and other status effects where you want to change the appearance of the player but don’t want to have to set up a potentially complex other actor and set of logic hooks for this different looking version of the player.

I think this makes sense, haha.

[Pyromania]

Any chance of getting a port of Scorpion Engine for macOS?

[earok]

@pyromania no plans at the moment

@amigaosx tooltips would be good, and I like the idea of integrating documentation into the engine (which I've done in other places eg with the pop ups of control types) but it's another thing I'll need to find time for

---

Experimental update is in. Now, I expect there may be a few breaking bugs with this, one major change in particular is the actor speed no longer changes when an actor type changes (the actor speed is only set when the actor is spawned).

This should make it easier to make objects that "slide" on ice for example but it may mean that some actors need to be changed to accommodate this (eg, the dead bodies on Amigo the fox needed to be changed to movement type "none" otherwise they'd keep sliding with the momentum they had before)

I may need to revert that if it causes any major breaking bugs or causes situations where something that worked before can't easily be fixed.


Another major change is the multiplayer control types have been dropped - instead, if you want your control or platformer character to be controlled by players 2-4, set from the Class dropdown

Also - another fix for var data, hopefully this resolves the issues with recycling now.

[Pyromania]

How long does it take to learn how to use Scorpion Engine?

[UltraNarwhal]

Originally Posted by earok

Experimental update is in. Now, I expect there may be a few breaking bugs with this, one major change in particular is the actor speed no longer changes when an actor type changes (the actor speed is only set when the actor is spawned).

Thanks vars seem fine now.

Can I vote for reverting to allowing speed changes on actor change, as it breaks some of my enemy stuff. Before when I hit enemies they could speed up/down, but now to do this I need to spawn and delete enemies and somehow transfer variables between them (not figured that out yet).

[UltraNarwhal]

Originally Posted by Pyromania

How long does it take to learn how to use Scorpion Engine?

It depends, bit like how long does it take to learn to read/write/draw/walk.
Easier to use than many other game engines though.

[Mixel]

Originally Posted by UltraNarwhal

Thanks vars seem fine now.

Can I vote for reverting to allowing speed changes on actor change, as it breaks some of my enemy stuff. Before when I hit enemies they could speed up/down, but now to do this I need to spawn and delete enemies and somehow transfer variables between them (not figured that out yet).

I can see advantages to both methods.. (though it definitely helps with my ice blocks and a couple of other things, I suspect a lot of my monsters are being strange if I go back and revisit them right now, haha!)

In one of the cases I had where it was being weird when I changed actor types - I fixed it by putting an actor stop movement and resume movement on either side of the change actor type, then it feeds it the actor’s new speed like it used to. (Not sure if this’ll work in all situations though!

vars are also fixed for me.