[WIP] Creeping Me Out!

[Mixel]

[ Show youtube player ]

Semi functional frogs in a semi functional swamp!

[earok]

Originally Posted by Mixel

[ Show youtube player ]

Semi functional frogs in a semi functional swamp!

Love it

[Mixel]

Thanks! Started on the snails too, very weak sauce puzzle enemies.

I’ve not been able to work on this for a bit as I’m not at home but I’ll have some fun CMOhn and non CMOhn scorpion stuff to share soon.

[Cobe]

Its all coming along very nicely!

[Tsak]

Yes, looks superb mate!

[Mixel]

Thanks all, progress has been slow since I got back from holiday, then I’ve been ill again. >.< Also rejigging my work setup a bit and had a day where Tiled wouldn’t load for some mysterious reason, haha. Oh well!

Here’s some molluscs.
[ Show youtube player ]

I’ve been wondering what to use as flying enemies in the swamp as I have a bunch of possible candidates already drawn, but I think I’ll do some sort of wil-o-the-wisp thing instead.. (I have flying skulls, spooky ghost girls, bats and the bugs you’ve all seen in the demo so far..) At this point in Zombie Holiday there were occasional ghost girls who fired ghost skull projectiles but I don’t think either enemy fit thematically in this new swamp.

[saimon69]

Well,a swamp need a muddy creature of the black lagoon and gators ,is a de facto standard

[Silverstreak]

Hey @Mixel. Looks amazing as ever, I had a couple of questions about your approach in developing this game. I've been stalking the Scorpion thread, but didn't want to derail the discussion!

How did you settle on a main character size? Are there any limitations, or did you just get lucky?

How do you handle versions and development history in Scorpion. I've only played around with it so far, and all I've managed to do is stop some of the demos from working! Is there an undo, or does it save a history?

Thanks!

[Mixel]

Hi! I love questions like this! Thanks, I'm glad you like the look of it so far..

Character size was after a ton of iteration, originally I had a bigger version from when I'd come from off the back of Zombie Holiday (1024x768ish screen resolution) thinking I was going to downsize to "retro size" 640x480 for a windows game, but that 64px high version of Francis felt huuuuge when imported into Scorpion, towering over the tiles, haha.

Attachment 72910
(here's my earliest attempt at getting francis is scorpion)

After thinking about the 16px grid used for platforms, and how I wanted jump heights to work (approximately like Turrican) I ended up with 32x48 limit for my characters.. (they're usually technically smaller, that's just the bounds I gave myself to work in) I tried 32x32 but couldnt get the amount of details I wanted. A more experienced pixel artist probably could though!



There's not reallllly a hard limit because I'm using Bobs, but the more and bigger things are the more chipram it uses up and the bigger performance cost blitting it.. (and if you use EHB64 like a doofus it uses up even more, stuff like this is why I've had to cut back graphics quite drastically in the no fastram build).. If I was using sprites for the player I would likely force him to fit in 32x32 somehow as then he'd be made of four 16*16 sprites (two 16px wide sprites -vvv- see Tsak’s comment below, haha!), but I'm using sprites for a lot of enemies, particle effects, explosions, bullets etc instead.

Sorry if you already know lots about this stuff but might be handy for other people reading, as it was all new to me..

For versions in development, I use Github desktop https://desktop.github.com/ - it was Earok's idea to use Git and I was a bit apprehensive about it because I'd never used it before (and know nothing about dev, LOL), but if you push your code to git it has a comment field for every commit and it's really easy to selectively revert changes to individual files, basically like an Undo button.. I've had to do that SO many times, haha. It's also super handy if you need to invite someone else to help with the project.

I also sometimes make a local backup of the project folder when I know I'm doing something potentially destructive, or using a new version of Scorpion with big new features.

Installing GitHub desktop and Subbing to the Scorpion repositories basically means you have an auto-updater for Scorpion too, so while I was worried about making things complicated for myself it actually streamlined/made things a lot simpler.


(they list when there are updates available, and show number of local changes since last commit, etc!)

[Silverstreak]

Originally Posted by Mixel

Attachment 72910
(here's my earliest attempt at getting francis is scorpion)

Whoah!!! He's huge

Thanks they are some great tips, I've now copied that and set myself up in a similar way, and I have absolutley NO idea what I'm doing but I can see how publishing out is helpful, it really keeps a track of everything!

I'm a little bit nervous about starting something, it's a bit daunting, but I'm in no rush.

Thanks again, your game looks great.

[Mixel]

Originally Posted by Silverstreak

Thanks they are some great tips, I've now copied that and set myself up in a similar way, and I have absolutley NO idea what I'm doing but I can see how publishing out is helpful, it really keeps a track of everything!

I'm a little bit nervous about starting something, it's a bit daunting, but I'm in no rush.

I was the same. I still sometimes feel like I only vaguely know what I’m doing, haha. I’m enjoying the puzzle-like nature of it though. It’s great that Scorpion uses things like Tiled, which is somewhat of a standard, too, end up learning so many different apps/disciplines that I’ve wanted to know forever! I hope it doesn’t get too daunting. Ask lots of questions.

Would you put what you’re making in The Amiga Show?

[Silverstreak]

Ha!... Well I'd have to make another episode for that to happen! The show is still going on, but work is taking up a lot of time at the moment, and it's hard to fit the show in around it, so it's had to go on a short pause.


However, chipping away at a project on Scorpion could be an achieveable thing. Maybe it could become part of the Show. I'm not interested in selling a game, but I do have an idea that might be fun.

[Tsak]

Originally Posted by Mixel

After thinking about the 16px grid used for platforms, and how I wanted jump heights to work (approximately like Turrican) I ended up with 32x48 limit for my characters.. (they're usually technically smaller, that's just the bounds I gave myself to work in) I tried 32x32 but couldnt get the amount of details I wanted. A more experienced pixel artist probably could though!

Just a sidenote about this. Amiga OCS sprites are 16px width and UNLIMITED height. I.e. you can still fit your 32x48 character with only 2 sprites (or should I better say 4 because the character is more than 3 colors, hense you'd be using 'attached sprites' instead of normal ones).

*edit, clarifying what 'attached sprites' means: normal OCS sprites (and AGA ones) can only be 3 colors each (+ transparency). By combining 2 sprites together you can make them use 15 colors plus transparency instead =the whole range of the sprites palette. Each 'attached sprite' has the same size limitation as normal ones i.e. 16px width and unlimited height. In general there are 8 sprites available on Amiga, which means that when it comes to attached sprites you can only use 4 instead. Using a combination of attached and normal sprites (for different or the same gfx) is also possible .

All the above stand true for both AGA and OCS sprites with the following exceptions for AGA:
1) the sprites palette is completely seperate from the normal palette, meaning if your game is 32 colors f.e. you can get it to be 48 instead using sprites
2) you can instruct AGA to output 32px or 64px width sprites (still unlimited height). The downside of this is that you cannot combine 16 with 32 or 64, you have to choose one profile and stick with it. This means that assigning a very tiny gfx to be a sprite while you have selected 64px width f.e. is gonna eat up a ton of extra ram.

[Mixel]

Originally Posted by Silverstreak

Ha!... Well I'd have to make another episode for that to happen! The show is still going on, but work is taking up a lot of time at the moment, and it's hard to fit the show in around it, so it's had to go on a short pause.

Looking forward to it but there's no rush, it has an awesome timeless quality from the way you produce it anyway.

However, chipping away at a project on Scorpion could be an achieveable thing. Maybe it could become part of the Show. I'm not interested in selling a game, but I do have an idea that might be fun.

That's great! Good luck. I usually find it pretty chill.. And sometimes you have these great eureka moments when you think of a totally stupid seeming but functional way of making something work. (in a way that's something I'm loving about there being no big comprehensive manual, though there's probably a better way of doing a million things I'm doing there's almost no way for me to know about it, so it's less discouraging, haha)

Originally Posted by Tsak

Just a sidenote about this. Amiga OCS sprites are 16px width and UNLIMITED height. I.e. you can still fit your 32x48 character with only 2 sprites (or should I better say 4 because the character is more than 3 colors, hense you'd be using 'attached sprites' instead of normal ones).

Ooh, Of course! I didn't fully realise that. That explains why/how the parallax is how it is! Derp. Thanks.

*edit, clarifying what 'attached sprites' means: normal OCS sprites (and AGA ones) can only be 3 colors each (+ transparency). By combining 2 sprites together you can make them use 15 colors plus transparency instead =the whole range of the sprites palette. Each 'attached sprite' has the same size limitation as normal ones i.e. 16px width and unlimited height. In general there are 8 sprites available on Amiga, which means that when it comes to attached sprites you can only use 4 instead. Using a combination of attached and normal sprites (for different or the same gfx) is also possible .

In my case the subset of colours I have in slots 17-28 is not suitable for the player graphics, or a lot of things.. It's great for explosions and ghosts and impact effects etc though. I think I generally keep things to few enough for it to sprite them unattached too, if it automatically does that?

All the above stand true for both AGA and OCS sprites with the following exceptions for AGA:
1) the sprites palette is completely seperate from the normal palette, meaning if your game is 32 colors f.e. you can get it to be 48 instead using sprites
2) you can instruct AGA to output 32px or 64px width sprites (still unlimited height). The downside of this is that you cannot combine 16 with 32 or 64, you have to choose one profile and stick with it. This means that assigning a very tiny gfx to be a sprite while you have selected 64px width f.e. is gonna eat up a ton of extra ram.

AGA sounds like more of a headache than anything else, haha. I think I'd definitely need to design a game around its strengths, because that would take a totally different type of palette planning. I think I can see why so many AGA games seemed like not a big jump with that sort of limitations.

[Tsak]

Originally Posted by Mixel

In my case the subset of colours I have in slots 17-28 is not suitable for the player graphics, or a lot of things.. It's great for explosions and ghosts and impact effects etc though. I think I generally keep things to few enough for it to sprite them unattached too, if it automatically does that?

Well, first they need to be strictly 3 colors otherwise it will most certainly render them as attached. Then the palette needs to be also sorted in a very specific manner, f.e. 17 color is always used as transparent (in both attached and normal sprites) and then it's 4 colors for every 2 sprites with the first of the 4 always used as transparent. F.e. sprite 1-2 will use colors 17-20, then sprites 3-4 use colors 21-24 (21 is used as transparent in this case), 5-6 use colors 25-28 and 7-8 use colors 29-32. This means that if f.e. white is used in all your sprites then it needs to be in every single subset of colors.

So as you see it's extremely restricting in general. Because on OCS the sprites palette is also shared with bobs, this means that for most cases you need to butcher your color range if you really want to make use of non attached sprites (that's another huge plus of AGA sprites having a seperate palette). Also means you need to carefully plan what is used and where and how many sprite channels are allocated to what gfx. Overal it's quite complicated and for this reason I doubt Scorpion does any of this automatically (re-arranging the palette would mess up the bobs). If you don't follow the above rules then I'm 99% sure Scorpion will render them as attached (even if they are indeed 3 colors) or worst not render them as sprites at all but bobs instead.

[acidbottle]

Originally Posted by Mixel

That's great! Good luck. I usually find it pretty chill.. And sometimes you have these great eureka moments when you think of a totally stupid seeming but functional way of making something work. (in a way that's something I'm loving about there being no big comprehensive manual, though there's probably a better way of doing a million things I'm doing there's almost no way for me to know about it, so it's less discouraging, haha)

...

AGA sounds like more of a headache than anything else, haha. I think I'd definitely need to design a game around its strengths, because that would take a totally different type of palette planning. I think I can see why so many AGA games seemed like not a big jump with that sort of limitations.

Am pleased to hear it is not just me just seemingly randomly blitzing away with actually no real clue what is going to happen until compile time .. which is frequent and often! I do know others have done in several lines of codeblock that I managed to turn into an entire screen haha

The palette thing for me is still really a bit of dark art. If you stick to OCS it is pretty straightforward, especially if you design your gfx from scratch. Games like CMOhn benefit as it gives the visuals an awesome and distinct style to

[Mixel]

Originally Posted by Tsak

Well, first they need to be strictly 3 colors otherwise it will most certainly render them as attached. Then the palette needs to be also sorted in a very specific manner, f.e. 17 color is always used as transparent (in both attached and normal sprites) and then it's 4 colors for every 2 sprites with the first of the 4 always used as transparent. F.e. sprite 1-2 will use colors 17-20, then sprites 3-4 use colors 21-24 (21 is used as transparent in this case), 5-6 use colors 25-28 and 7-8 use colors 29-32. This means that if f.e. white is used in all your sprites then it needs to be in every single subset of colors.

Ahhhhhh that makes sense. That sounds like a headache to work with haha. My palette isn't set up at all for that so even if unattached sprites were supported it doesnt sound like I'd be using them.

Originally Posted by acidbottle

Am pleased to hear it is not just me just seemingly randomly blitzing away with actually no real clue what is going to happen until compile time .. which is frequent and often! I do know others have done in several lines of codeblock that I managed to turn into an entire screen haha

Yup you end up learning all the time at least.. Fortunately. By the end of CMOhn I expect it to take an age to compile (it already take ~1Min, so it'll definitely take 5m, maybe 10m or more at this rate!) so if I couldn't build from my old codeblocks and was guestimating everything each time that could get painful haha.

The palette thing for me is still really a bit of dark art. If you stick to OCS it is pretty straightforward, especially if you design your gfx from scratch. Games like CMOhn benefit as it gives the visuals an awesome and distinct style to

TY! My other project just has 16 colours and no parallax so those colours are really, really easy to deal with in that case.. EHB kind of makes everything non-straightforward: Your scales have the dark half in the dark half of the palette, unusable by sprites.. So if you want to use the sprite colours for things like the player it becomes very hard unless you have a totally different art style to what I'm using. Then 3 colours sacrificed to parallax and 3 more sacrificed to being the halfbright counterpart to those 3 colours... Buuuut.. All those 6 colours reactivate when you go to a level where you have no parallax, so I had think about colours i dont really need outdoors, but can use in interiors sometimes.

I like to try to get the palette nailed down as the very first thing, because it impacts everything down the line. I really wish Aseprite supported 12bit only colour as an option. Grr. (not that we're short of choices that do have that as an option, it just seems like a glaring omission!)

[Samurai_Crow]

Originally Posted by Mixel

I like to try to get the palette nailed down as the very first thing, because it impacts everything down the line. I really wish Aseprite supported 12bit only colour as an option. Grr. (not that we're short of choices that do have that as an option, it just seems like a glaring omission!)

There is only enough bandwidth for 6 bits per pixel maximum. HAM mode uses bandwidth compression to give you 4096 color graphics from lossy, 50% ratio, color fringe inducing bandwidth reduction. BOBs don't work in HAM mode which limits you to 4 attached sprites horizontally from each other. For obvious reasons, HAM mode is only used for full screen billboards and ANIMs.

[Mixel]

Umm.. I don't see what that has to do with anything? Hehe.

I'm talking about choosing colours that are displayable by OCS amigas.. Being able to limit the app to only work in 12bit (4096 colours) helps design the palette.

When I'm designing the copper/parallax layers too - they involve a lot of gradients and they're difficult to do easily in Aseprite because it doesnt support bit limitations, so I use Pro Motion NG, where I can just bung 4/4/4 in the channel settings and only pull from the 4096 colours that actually exist.

[Samurai_Crow]

Sorry. I thought you were looking for 12 bit high color mode.