Scorpion Engine

[Clydos]

It is not about character specifics. My question is about the possibilities of this engine.

[earok]

I hadn't really planned to support multiple-push in the engine.

Single push is an extremely simple and a reasonably common mechanic, but multiple push adds complexity and a little more performance overhead (rendering multiple moving blocks at a time).

Having said that - if someone was using the Scorpion engine and needed that as an important mechanic for their game, I'd certainly consider it.

[malko]

earok, push from right/left/bottom seems OK. But from the top it seems to me that there is a "space" like if Link was not touching the wood and thus "pushing at distance".

[earok]

Originally Posted by malko

earok, push from right/left/bottom seems OK. But from the top it seems to me that there is a "space" like if Link was not touching the wood and thus "pushing at distance".

There was indeed an engine bug with collision boxes, now fixed, thanks for pointing it out

[malko]

Originally Posted by earok

There was indeed an engine bug with collision boxes, now fixed, thanks for pointing it out

You are welcome And thank you for this 'scorpion engine'

[earok]

Cheers Malko I hope I can eventually deliver a decent gamemaking kit!

Did a fair bit on Saturday around "block" interaction.



The setup we've got here is that we've defined a collision rectangle inside of Link's sword frame. When we do an attack, it checks the overlapping tiles to see if we've got any "blocks" (such as these bushes).

=== HITBUSH ===
~block_type = null
~dice = 2
{ dice == 1:
~block_type = rupee1
}
->Game

All we're doing here is, upon the bush being hit, we're setting the "type" of block to null (nothing), and doing a dice roll on a "2 sided dice" (eg, a coin - but the dice function supports any sized dice). If we get a 1, we replace the bush with a rupee.

[xboxown]

Originally Posted by earok

Cheers Malko I hope I can eventually deliver a decent gamemaking kit!

Did a fair bit on Saturday around "block" interaction.



The setup we've got here is that we've defined a collision rectangle inside of Link's sword frame. When we do an attack, it checks the overlapping tiles to see if we've got any "blocks" (such as these bushes).

=== HITBUSH ===
~block_type = null
~dice = 2
{ dice == 1:
~block_type = rupee1
}
->Game

All we're doing here is, upon the bush being hit, we're setting the "type" of block to null (nothing), and doing a dice roll on a "2 sided dice" (eg, a coin - but the dice function supports any sized dice). If we get a 1, we replace the bush with a rupee.

Are the plans in the future to deliver a full functioning RPG Maker like I posted in previous page in this forum, where a person can compile a full standalone game? I am just wondering!

[Clydos]

Originally Posted by earok

Having said that - if someone was using the Scorpion engine and needed that as an important mechanic for their game, I'd certainly consider it.

Thanks, earok! As for me it was just a question out of curiosity. No need to think about it currently. But I can I imagine that there might be potential for game ideas. We'll see.

[earok]

@xboxone

We're not specifically trying to match RPG maker's functionality, though I suspect that by the time we're finished, most of what you can do in RPG maker would be doable in this. We've already got branching dialogue, NPCs, event triggers. We don't really have anything specifically for handling turn-based combat but it could probably be done one way or another.

@clydos

No worries! I am definitely planning to add further functionality to how blocks work (I imagine a chips-challenge-esque game could be made if ice and conveyor belts were part of the core functionality).

[xboxown]

Originally Posted by earok

@xboxone

We're not specifically trying to match RPG maker's functionality, though I suspect that by the time we're finished, most of what you can do in RPG maker would be doable in this. We've already got branching dialogue, NPCs, event triggers. We don't really have anything specifically for handling turn-based combat but it could probably be done one way or another.

@clydos

No worries! I am definitely planning to add further functionality to how blocks work (I imagine a chips-challenge-esque game could be made if ice and conveyor belts were part of the core functionality).

Actually this is not I was asking earok I prefer it like this in terms of battle engine although I would love a more complex and improved AI then a monster just simply trying to touch you! I was asking for the editor where a person can use a click and play interface like RPG Maker I mean with a build in map editor, event editor, adding objects, etc without the need of script. This is what I was hoping! Like the editor simply compile the game into the interpreter script like you just pasted in the forum and the user all he or she have to do is double click the choices of events without the need of coding, like RPG Maker. I am wondering if in the future such thing is planned and it will use MUI and be workbench friendly.

In the future are there plans to add your own weapons, armors, be able to change the graphics of the tiles, heros, weapons, etc by the click of a mouse button? I would love to use Zelda's engine for example to have a futuristic theme of modern time, or advanced science fiction time of aliens, etc or have a game genra of the era of the dinasours, etc.

Thanks in advance!

[earok]

There's no plans for a workbench editor or a visual editor (asides from the use of tiled for level creation). Scripting and configuration is all done with text files.

[xboxown]

Originally Posted by earok

There's no plans for a workbench editor or a visual editor (asides from the use of tiled for level creation). Scripting and configuration is all done with text files.

Alright - cracks fingers - I guess this is my next project then!! - deep sigh - I guess I have no choice but to do it myself then!! I suppose a man gotta to do what a man gotta to do, not rely on people and do it himself!

Tell me when you are finished with the engine and show me the scripts, I will simply learn in the meantime AmiBlitz and practice writing MUI applications left and right.....once I mastered I can simply write my own Application to convert everything into a script .txt file where the engine can read it on the fly.

Aaaah.....- deepest sigh possible - ooooo well.

[earok]

Originally Posted by xboxown

Alright - cracks fingers - I guess this is my next project then!! - deep sigh - I guess I have no choice but to do it myself then!! I suppose a man gotta to do what a man gotta to do, not rely on people and do it himself!

Tell me when you are finished with the engine and show me the scripts, I will simply learn in the meantime AmiBlitz and practice writing MUI applications left and right.....once I mastered I can simply write my own Application to convert everything into a script .txt file where the engine can read it on the fly.

Aaaah.....- deepest sigh possible - ooooo well.

Here's the thing.

The Scorpion Compiler relies on a few different components which would make porting to a graphical Amiga environment extremely difficult.

The configuration file (simply things like how fast a player or NPC can move, where level files are etc) is probably something that could be driven by a graphical user interface.

There's the Ink-based scripting language that controls events, dialogue, menus and such. Ink is one of the most simple scripting languages out there, but like any language it'd be difficult to turn it into something purely visual.

Then there's the animations, which are created with the Spriter Beta (only on Windows). Fortunately, the spriter file format is very simple so a replacement app could be written, but it'd still be another thing to take care of.

The levels are created with Tiled, which is fortunately open source, but I can't imagine how difficult it'd be to port to OS3.

And finally there's the compiler, which puts it all together - serializes the configuration file and all of the Spriter animations to raw bytes, turns all of the images from source PNGs to raw bitplanes, and compiles the Ink script to bytecode.



I think, to be honest, if you're really keen on keeping your development environment purely Amiga, it may be best to look at something like Redpill or creating something from scratch.

[saimon69]

Is a bit OT here but i think if someone create a runtime engine in assembly for RedPill that would easily cover 90% of new game development on Amiga being faster than Blitz runtime, but that is me and i also might be wrong

[xboxown]

Originally Posted by saimon69

Is a bit OT here but i think if someone create a runtime engine in assembly for RedPill that would easily cover 90% of new game development on Amiga being faster than Blitz runtime, but that is me and i also might be wrong

The only thing I find discouraging about Red Pill it is not very user friendly,

[earok]

I've done a whole lot of work on it lately, so I need a little breather for a few days.

Here's some of the stuff that's new.

* I've implemented idrougge's library for PHX's PTPlayer. What that means essentially is that you won't need to worry about assigning channels for music and SFX for a game - just set it and forget it, even on a four channel song it'll intelligently squeeze SFXs on to a channel, based on how long until the next note plays.

* More kinds of event triggers, so that custom scripting can be used for a more flexible game. Some examples of these

- PlayerCollision, so we can handle what happens when a player runs into an enemy

- PlayerDialogue, this is a custom event for handling when a player interacts with an NPC. It also has an affect on the movement behaviour of the NPC itself (if it's close enough for the player to talk to it, it'll stop and look at the player)

- PlayerHit, so we can handle what happens when a player melee strikes an enemy.

- Timer, so we can have an event that triggers on a regular interval - say every second, or even every frame. We could use this to have an arcade-style time limit, or use it to move the camera in a custom way.

* More kind of movement controllers, which include

- Player_RPG: Currently, the only kind of player controller. Handles movement in a "Zelda" esque way.

- NPC: The basic NPC type. Doesn't really do anything special. It can be set to move at a constant speed, but won't collide with walls. You could use this for effects or collectables.

- NPC_Bounce: As above, except it'll bounce off walls.

- NPC_Path: Follows a fixed, pre-defined path.

- NPC_Pursuit: Pursues the player. Has some rudimentary intelligence for navigating mazes.

* Various performance enhancements, mainly to do with redrawing "dirty" tiles in such a way that no tile is redrawn twice (eg, if two objects are overlapping, it won't redraw the tile underneath them more than once)

This upcoming weekend is the Kiwi Jam gamejam event, I might use that to look at doing a third sample game.

[xboxown]

Thaaank you!!!!!

[Clydos]

Yeah, this sounds great, thanks, earok!

Not sure whether it was already mentioned, but what language do you use to code the Scorpion Engine (btw, I like the name a lot!)? BlitzBasic?

[earok]

Cheers xboxone clydos! I hope to deliver something cool in the short term future.

It's indeed using Blitz Basic, but with bits and pieces of pure assembly (mainly for handling the blitter - and of course, external libraries such as PTPlayer are 100% ASM). I'll probably continue porting more bits and pieces to pure assembly as the codebase becomes more fixed.

[earok]

Some hackery for the Kiwi Jam event. I don't currently have the platformer module engine in the game yet, so Alex can only swim right now.



I've made a log of the steps I've gone through (tools used etc) to get to this point.

https://twitter.com/earok/status/1152164857073946624

Edit: Saturday progress.

[ Show youtube player ]

https://twitter.com/earok/status/1152369992689565697