Scorpion Engine

[Dunny]

Well, ok. Let's wait until it's been released.

[earok]

Couldn't sleep. Did a bit more on the tutorial... obviously, the character is a place holder.

[spoUP]

Kick ass work earok!

[earok]

Cheers

Time for another TOG mini tutorial. This one is fairly advanced, but I did want to talk about the possibilities for what the Scorpion Engine can do through it's block management system - which is flexible enough that it could theoretically power a game like Lode Runner, Boulder Dash or DynaBlaster.

So what I've written is likely to be confusing, but I'm happy to elaborate if anyone has any specific questions.


There's a level near the end of part 1 of TOG where the player has to dig through a mine. The destroyable walls are implemented the same as the bushes were in the previous tutorial - as active objects rather than static blocks, so they're costly in terms of the CPU and blitter, and they will slow the game down a lot if there's more than 1 or 2.

But we can't do exactly the same as we did with converting the bush from an object to a block - the destroyable walls are 32x32, and we want to be able to hit any corner of them to collapse the entire wall. Fortunately, Scorpion can handle it.

Firstly, we need to add four new blocks to our tileset, and then add those blocks to the level. We'll name them BreakBlockTL, BreakBlockTR, BreakBlockBL, BreakBlockBR



Next, we want to add these blocks into our Project.Txt file.

[Block BreakBlockTL]
source=sprites\talesofgorluth-enemy-blk\000.png:0:0
solid=true
divert_playerprojectilecollision=BreakBlockTL_Hit

[Block BreakBlockTR]
source=sprites\talesofgorluth-enemy-blk\000.png:16:0
solid=true
divert_playerprojectilecollision=BreakBlockTR_Hit

[Block BreakBlockBL]
source=sprites\talesofgorluth-enemy-blk\000.png:0:16
solid=true
divert_playerprojectilecollision=BreakBlockBL_Hit

[Block BreakBlockBR]
source=sprites\talesofgorluth-enemy-blk\000.png:16:16
solid=true
divert_playerprojectilecollision=BreakBlockBR_Hit

Depending on which of the four corners we hit with our sword, the code to handle the collapsing wall is different, which is why we're calling four different routines from "divert_playerprojectilecollision". So finally, we add code to project.ink:

=== BreakBlockTL_Hit ===
//Play the destroy sound
~ Sound = SndUNIVERS2

//Destroy the player's projectile
~ PlayerProjectile_Type = null

//Destroy this block and the surrounding three
~ Block_Type = null
~ Block_X = Block_X + 1
~ Block_Type = null
~ Block_Y = Block_Y + 1
~ Block_Type = null
~ Block_X = Block_X - 1
~ Block_Type = null
~ Block_Y = Block_Y - 1

//Spawn a block break animation object from the top left corner
~ Block_Spawn = ENEMY_Block_die
-> GAME

=== BreakBlockTR_Hit ===
~ Block_X = Block_X - 1
-> BreakBlockTL_Hit

=== BreakBlockBL_Hit ===
~ Block_Y = Block_Y - 1
-> BreakBlockTL_Hit

=== BreakBlockBR_Hit ===
~ Block_X = Block_X - 1
~ Block_Y = Block_Y - 1
-> BreakBlockTL_Hit

Here we're manipulating the 'block pointer', the X/Y co-ordinates that allow the scripting engine to change any block on the map in real time. If we hit any block other than the top left block, we move the block pointer to the top left block and execute the routine for handling a hit on that block.

From there, we do the following:

- Play the block destroy sound
- Destroy the thrown sword
- Spawn the block wall destroy animation (this is a simple object that plays an animation, and then deletes itself from the game)
- Destroy the top left block, as well as the surrounding three

Here's what it looks like

[Clydos]

Great progress, earok! And thanks for the tutorials.

I struggle a bit with, what is a keyword and what is a self defined variable. E.g. are Block_Type and Block_X/Y are reserved words?

And the line "Block_X = Block_X + 1" sets the pointer to the next block and the following "Block_Type = null" destroys this current block, right?

[earok]

Originally Posted by Clydos

Great progress, earok! And thanks for the tutorials.

I struggle a bit with, what is a keyword and what is a self defined variable. E.g. are Block_Type and Block_X/Y are reserved words?

And the line "Block_X = Block_X + 1" sets the pointer to the next block and the following "Block_Type = null" destroys this current block, right?

Cheers!

They are special variables that have certain side-effects in the engine when they're set. The list of them is at https://github.com/earok/scorpion-en...ters/README.md

Setting Block_Type = null does destroy the block. But alternatively, we could set it to a different block type. For example, if we had coins underneath the wall, we could use something like "~ Block_Type = Coin" to change the wall section to a coin.

[Clydos]

Thanks earok! Sorry that I didn't RTFM. :-(

Very nice with the simple "block type casting". Neat!

[earok]

I had bit of a setback with my laptop, and had to Reinstall Windows 10 and I've only just been able to get back into doing some Scorpion things :/ anyway, new mini tutorial.

The second mine level of TOG1 has two different kinds of block walls than the previous one:
- It has walls that can just be walked through, but cannot be torn down, and..
- It has walls that need five shots to destroy.

Implementing the first kind is super easy. We just need to add the tiles to the foreground layer.



Note that we also need to draw those tiles on the background layer. Scorpion only renders foreground tiles when there's actually something behind them.

The second bit is a little harder. Blocks don't have variables per se, so we can't just assign a health value to them. But what we can do is make identical blocks and handle them a little differently in code. Let's add four new blocks to the project.txt file:

[Block BreakBlock5]
source=sprites\talesofgorluth-enemy-blk\000.png:0:0
solid=true
divert_playerprojectilecollision=BreakBlockTL_Hit

[Block BreakBlock4]
source=sprites\talesofgorluth-enemy-blk\000.png:0:0
solid=true
divert_playerprojectilecollision=BreakBlockTL_Hit

[Block BreakBlock3]
source=sprites\talesofgorluth-enemy-blk\000.png:0:0
solid=true
divert_playerprojectilecollision=BreakBlockTL_Hit

[Block BreakBlock2]
source=sprites\talesofgorluth-enemy-blk\000.png:0:0
solid=true
divert_playerprojectilecollision=BreakBlockTL_Hit

These represent the blocks at health levels 2, 3 4 and 5.

Next, we need to expand the routine from the previous tutorial:

=== BreakBlockTL_Hit ===
//Destroy the player's projectile
~ PlayerProjectile_Type = null

{ Block_Type == BreakBlock5:
	~ Block_Type = BreakBlock4
	-> GAME
}
{ Block_Type == BreakBlock4:
	~ Block_Type = BreakBlock3
	-> GAME
}
{ Block_Type == BreakBlock3:
	~ Block_Type = BreakBlock2
	-> GAME
}
{ Block_Type == BreakBlock2:
	~ Block_Type = BreakBlockTL
	-> GAME
}

//The rest of the code is the same as last time

So each time we run the code for handling a hit, we change the block to a block representing a lower level of health.

@Clydos, technically there's no "type casting" in Scorpion. There's only one data type at the moment (16-bit signed integer). The block names here (BreakBlock2, BreakBlock3 etc) are constants generated by the compiler that link the name of the block to the numeric ID. So when we set the variable block_type, we're assigning it a numeric value, which in turn signals to the Scorpion Engine that we want to change the block.

[earok]

Time for a quick update.

Tales of Gorluth Scorpion is at Amiga34 at the Amiwork's booth this Saturday.



I haven't had a lot of time to spend on the engine itself lately, but I've decided to get back into working on some of the core features.

One of the things I've done lately is massively simplified importing of several types - you no longer need to declare levels (.tmx), sounds (.8svx), protracker (.mod) or spriter (.sprtr) animation files in protect.txt, you just need to have them in the project folder, and then you can immediately use them in the game.



Simply having a TMX file in the project folder means we can call it from script. Note that this does mean that filenames for those types should be globally unique (for example, I can't have a level1.mod file since there would be two entities with that name - I would have to use something like level1song.mod).

I've got a whole bunch of things to balance with the project, but I'm definitely keen to work towards a vastly simpler way of developing Scorpion projects (eg, something vaguely Unity Editor-esque)

[malko]

Excellent !

[earok]

I ended up going down the rabbit hole and started development on an IDE of sorts for the Scorpion Engine. It might be a little while before it's fully usable, but I'm getting quite excited about it.

[Clydos]

Originally Posted by earok

Simply having a TMX file in the project folder means we can call it from script. Note that this does mean that filenames for those types should be globally unique (for example, I can't have a level1.mod file since there would be two entities with that name - I would have to use something like level1song.mod).

Cool thing! But would it be possible to put those files into separate folders (which makes sense anyway), like "levels/level1.tmx" so you would reference that in your project file like "~ level = levels/level1". This would also help with the problem of globally unique names a bit.

IDE: Very nice, will come handy for sure!

[earok]

The IDE is coming along nicely. Though it does mean that, with how I've restructed the data, I'll need to do some work getting all the other demos + the TOG ports to work with it.

That's a good point @Clydos, though I'd rather avoid adding string support at this stage (excluding for dialogue), and having / in a constant name is problematic (since it's the divide symbol). But I'll keep thinking about the issue.

[Clydos]

Originally Posted by earok

That's a good point @Clydos, though I'd rather avoid adding string support at this stage (excluding for dialogue), and having / in a constant name is problematic (since it's the divide symbol). But I'll keep thinking about the issue.

I see your point. No problem. But good to know you think about it.

EDIT: BTW, what language/framework do you use to program the IDE?

[Retro1234]

Earok


Ok not Scorpion but close enough.

[earok]

Heh. I do get that reference.. and occasionally someone does refer to it as the 'Scorpio Engine' rather than Scorpion.

I guess I'm well overdue for an update. I haven't been super productive lately, but the new IDE is coming along. Honestly, making an IDE was far easier than I assumed, but it's still frustrating and difficult at times.

I'm sort of using Unity as my inspiration - pretty much all assets (including Actor and Block data) are all separate files, which is handy for version control, as well as transferring assets between projects.

I've also done a bit of work on automating the creation of Tiled files - when I'm done, it should all be as simple as selecting "new level" from a menu and you'll have a completely configured level that you can start to populate, whereas before there was a fair bit of manual work involved. At some stage, I want to have a look at some rudimentary WinUAE support (so that opening WinUAE and immediately running the game is more or less just a button click in the editor)

I'm not too far away from getting the IDE posted to Github, but to start with it'll only support the Alex Kidd demo and its related functionality - it'll take a bit longer before the Zelda and Phoenix Wright demos are working again, and a little longer still before Backbone import is running again.

[Tigerskunk]

Damn, this is gonna make us Amiga coders worthless...
Nice effort, Earok!

[earok]

Originally Posted by Steril707

Damn, this is gonna make us Amiga coders worthless...
Nice effort, Earok!

Haha, no way man! But hopefully it'll be a useful tool one day.

Edit: and, cheers

[earok]

[ Show youtube player ]

Getting closer and closer to a launch of the visual editor / IDE for the Scorpion Engine. The most recent new feature is the ability to launch FS-UAE directly from the editor, allowing for the ability to instantly test new changes.

[malko]

Originally Posted by earok

[...] Getting closer and closer to a launch of the visual editor / IDE for the Scorpion Engine. The most recent new feature is the ability to launch FS-UAE directly from the editor, allowing for the ability to instantly test new changes.

IDE is win32 & win64 ?
or like FS-UAE win64 only ? (no more official win32 build)