Polymer Picker 2? - discovery phase

[sa_scott]

Hi everyone,

I'm pleased to see that - if the popularity sort is anything to go by - Polymer Picker has risen to page 3 in the list on the BBC Games Archive. Thanks for playing it, hope have enjoyed playing it

I've been noodling ideas for a sequel, and wanted to bounce a few ideas, and ask how it might be possible to realise it.

• the basic plotline concerns emptying rubbish out of an oceanic trench. You would have to control a robotic submersible, connected to a winch(?), and work your way down, collecting rubbish as you descend.
• when you reach the bottom, you then have to work your way back up
• if you hit the sides of the trench, damage is sustained. If too much damage is acquired, you implode and it's curtains.
• ocean currents would sway the submersible. Subsea quakes could invoke rocky debris to fall, which you would have to avoid.
• In terms of screen layout, the trench would necessitate a vertically narrow screen, with the sides representing the trench cliffs.
• As you descend, the sea colour turns from blue to black, but in a gradual manner. This requires increasing levels of blue/black mottling
• There would of course, be various items of sea life to admire/contend with.

I don't have any mockups as yet, but I guess the key here is some kind of smooth scrolling as you descend. Or whether an 'impression' of descent is more appropriate.
If the submersible has a line attached, how would the line redraw according to how much you move left and right. How would momentum via currents be realised? I would imagine similar physics to a lunar lander game would come into play here.
And of course, the million pound question - would BASIC/6502 hybrid be appropriate? I would imagine a custom screen layout would free up screen memory, but it's no use if the game ends up too slow.

Well, there you have it. Until ChatGPT can build a BBC Micro assembler game for me, I will entrust the Stardot membership's wisdom on how best to realise this idea (which is - let's face it - forever )

Thanks in advance!

[fizgog]

You could go for a 10K screen like mode 5 and do a palette swap in a few places down the screen, that will save you some memory

Probably best to mock up some designs first

[ChrisB]

And of course, the million pound question - would BASIC/6502 hybrid be appropriate?

I'd have to say 6502 all the way. I've been playing with some Basic/6502 equivalents and even for things that are not traditionally very taxing like keyboard handling BASIC introduces a significant delay. Start in BASIC and convert gradually.

A reduced width Mode 2 (since you are looking for vertical game-play in any case) will take 16K (and 0.5K less per horizontal line below 32 lines). You also get 1K extra of data from BASIC from the language workspace and the first 144 bytes of zero page without using more "interesting" areas of memory. Gives you 13.5K of space.

[jms2]

I like your idea, and what's more I have a gameplay suggestion for you!

We have a very minimalistic board game called "Deep Sea Adventure". It's a lot of fun to play and I think the gameplay mechanic could read across to your game very nicely. Essentially in the board game you have several players in one submarine, and they all have to venture out looking for treasure. Everyone is connected to a shared air supply. When diving down, each person uses one unit of air per turn, but for every piece of treasure they collect they need an extra unit of air per turn. Obviously you need to get back to the sub before running out of air.

How this works in practice is everyone starts off feeling very gung-ho, and dives down as far as possible (the better treasure is lower down). But then there comes the horrible realisation that you've overcooked it, as you struggle to get back before the air runs out. What's more, you don't actually find out the value of the treasure until you get back to the sub.

In a one-player game there are various aspects you could borrow: bigger bits of rubbish lower down, increased air usage the more stuff you collect, random damage sustained by the walls etc. You could also have bonus air tanks hidden in the walls.

I'm still struggling to see how the "rope" would be drawn and how it would appear - straight would be physically correct but would preclude very much twistiness of the shaft. But a curved rope would be weird wouldn't it? Maybe just the visible bit of rope is straight but allow the passage to move about with a longer "wavelength".

[fizgog]

Following game writer in basic has a rope with some sort of elevator on the end. Might give you some sort of idea how a rope descends and raises


http://www.bbcmicro.co.uk/game.php?id=1425

[sa_scott]

Following game writer in basic has a rope with some sort of elevator on the end. Might give you some sort of idea how a rope descends and raises


http://www.bbcmicro.co.uk/game.php?id=1425


Disc080-CatNapper.png

Oh man, Catnap. That was my first ever go at typing in a game listing. Of course, I left all the spaces between line numbers in, so was upset when it didn't work! I must have been 11 or 12 at the time.

Thanks for the memory!

[sa_scott]

I like your idea, and what's more I have a gameplay suggestion for you!

We have a very minimalistic board game called "Deep Sea Adventure". It's a lot of fun to play and I think the gameplay mechanic could read across to your game very nicely. Essentially in the board game you have several players in one submarine, and they all have to venture out looking for treasure. Everyone is connected to a shared air supply. When diving down, each person uses one unit of air per turn, but for every piece of treasure they collect they need an extra unit of air per turn. Obviously you need to get back to the sub before running out of air.

How this works in practice is everyone starts off feeling very gung-ho, and dives down as far as possible (the better treasure is lower down). But then there comes the horrible realisation that you've overcooked it, as you struggle to get back before the air runs out. What's more, you don't actually find out the value of the treasure until you get back to the sub.

In a one-player game there are various aspects you could borrow: bigger bits of rubbish lower down, increased air usage the more stuff you collect, random damage sustained by the walls etc. You could also have bonus air tanks hidden in the walls.

I'm still struggling to see how the "rope" would be drawn and how it would appear - straight would be physically correct but would preclude very much twistiness of the shaft. But a curved rope would be weird wouldn't it? Maybe just the visible bit of rope is straight but allow the passage to move about with a longer "wavelength".

There's some nice ideas in there. Some definite things to think about. I like the fact that the rope stays straight because of the length onscreen, but that you are swinging left and right because of movement and momentum.

[sa_scott]

And of course, the million pound question - would BASIC/6502 hybrid be appropriate?

I'd have to say 6502 all the way. I've been playing with some Basic/6502 equivalents and even for things that are not traditionally very taxing like keyboard handling BASIC introduces a significant delay. Start in BASIC and convert gradually.

A reduced width Mode 2 (since you are looking for vertical game-play in any case) will take 16K (and 0.5K less per horizontal line below 32 lines). You also get 1K extra of data from BASIC from the language workspace and the first 144 bytes of zero page without using more "interesting" areas of memory. Gives you 13.5K of space.

I figured that would be the case. I was trying to pick apart Monster Maze from the October 1989 Micro User as an exercise in deciphering the assembler. I compared the keyboard handling routine to those in say, Runemaker. But the latter is hard to read through because of its sheer length.

I'm gonna need some kind of assembler primer at some point. I may need to create a proof of concept just to get the ball rolling.

[ChrisB]

I was using the key read loop as something that was comparatively simple - and possibly OS based - rather than for example the sprite plotting routines which often take significant amounts of time and/or code. Even for a simple loop assembler will be around 10 times faster.

I uploaded the code to beebchase to github here https://github.com/ChrisB73/Beebchase. It's not the best code but is reasonably commented and because the game is quite simple there has been no real need to do clever tricks to get the most out of the hardware or compress the code (apart from the screen access). To go back to the keyboard routine that is only a few lines of code:

Code: Select all

    lda #5                  ; 6 keys to check
    sta temp1

.keyreadloop
    ldx temp1
    lda &88,X
    tax             ; Move key to be detected to X
    lda #121
    jsr osbyte      ; check if key pressed
    ;if x<0 pressed so move neg flag into keyspressed
    txa
    asl A           ; Move top bit to carry
    rol keyspressed ; Move carry to keyspressed
    dec temp1
    bpl keyreadloop

Locations &88 to &8E contain the keys to be checked. We call Osbyte 121 for each one of these and if it's pressed set a bit in "keyspressed". The bits are read out later one by one for each of the key actions (Fire,left,right,up,down,sound)

[sa_scott]

I was using the key read loop as something that was comparatively simple - and possibly OS based - rather than for example the sprite plotting routines which often take significant amounts of time and/or code. Even for a simple loop assembler will be around 10 times faster.

I uploaded the code to beebchase to github here https://github.com/ChrisB73/Beebchase. It's not the best code but is reasonably commented and because the game is quite simple there has been no real need to do clever tricks to get the most out of the hardware or compress the code (apart from the screen access). To go back to the keyboard routine that is only a few lines of code:

Code: Select all

    lda #5                  ; 6 keys to check
    sta temp1

.keyreadloop
    ldx temp1
    lda &88,X
    tax             ; Move key to be detected to X
    lda #121
    jsr osbyte      ; check if key pressed
    ;if x<0 pressed so move neg flag into keyspressed
    txa
    asl A           ; Move top bit to carry
    rol keyspressed ; Move carry to keyspressed
    dec temp1
    bpl keyreadloop

Locations &88 to &8E contain the keys to be checked. We call Osbyte 121 for each one of these and if it's pressed set a bit in "keyspressed". The bits are read out later one by one for each of the key actions (Fire,left,right,up,down,sound)

I think if I'm going to do this properly, it looks like I'll have to go the Beebasm route. I'll have to start browsing yours and other repos to get a sense of how this will come together.

I'm wondering about whether to use Mode 2 palette switching, along with poking the FX commands for flash speed to create the impression of descent, by drawing the cavern walls in particular flashing colours, then colour cycling at an increasing speed to imply quicker descent? I'm wondering if that is possible, or if there is another way of achieving this? 'Proper' scrolling is likely to be taking it too far, and I'd prefer not to have jittery scrolling (think JCB Digger, or Mike Goldberg's Car Race game).

I'll certainly take a browse of your code, Beebchase is quite a fun game to play, would be nice to examine the code behind it.

[fizgog]

I’m guessing you have a choice of 3 types of layouts, couldn’t think of any more types

1 static screen - possibly cramped gameplay though and you wouldn’t feel that you are going very deep
2 flip screen (like castle quests up down) - might make it hard to see what’s below when you get to the bottom
3 scrolling screen (what comes to mind are the loads of down hill skiing games) harder to code if you want it smooth though

[ChrisB]

Looks like fizgog beat me to it...

If you're going down the the 6502 route there is plenty of time to manipulate the palette directly allowing three (or more) colours to be used. That might make a more convincing direction. You would probably be limited to a "static" cavern though where the sides wouldn't change. I don't know how that would fit with your vision.

I wouldn't dismiss scrolling just yet - JCB's (famously) jerky scrolling is because the screen updates are not timed with the vsync. My Acorn Island's vertical scrolling is line by line in the same way and I don't think it suffers the same problem. And of course the single line scroll routine of Firetrack is (AFAIK) now well understood and could be used - but possibly overkill.

There is also the "screen flip" approach - either a partial or whole screen as a halfway house. Again - this will depend on the way you want it to look/feel.

[fizgog]

You might get away without using single line scrolling and stick with character scrolling, all depends on if you're game is fun enough and player is not concentrating on the scrolling.

Take a look at this simple downhill skiing game in basic, one of the best I found and it's very fun to play IMHO

http://www.bbcmicro.co.uk/game.php?id=2354

[tricky]

Have a look at Kieranhj's scrolling sample and his ABUG talk.

If you have vertical pixel scrolling of you main character then vertical scrolling in pixels doesn't make anything more difficult

I'm definitely a mode 1 fan but having lots of colours is good. If it is a narrow screen, do you need fine horizontal control?

If you have a nula version, you could do some nice pallet swapping to make it darker as you go down.

Test colour cycling first, it can be very distracting, but a game option to enable/disable would get around that.

Why a rope? Wouldn't a powered sub work too? If you have a tether, why no oxygen hose

[sa_scott]

Have a look at Kieranhj's scrolling sample and his ABUG talk.

If you have vertical pixel scrolling of you main character then vertical scrolling in pixels doesn't make anything more difficult

I'm definitely a mode 1 fan but having lots of colours is good. If it is a narrow screen, do you need fine horizontal control?

If you have a nula version, you could do some nice pallet swapping to make it darker as you go down.

Test colour cycling first, it can be very distracting, but a game option to enable/disable would get around that.

Why a rope? Wouldn't a powered sub work too? If you have a tether, why no oxygen hose

Thanks for your input tricky. And, good point about the need for a rope! May have been relevant if I was going for a steampunk approach! But plastic pollution wasn't a problem 100 odd years ago

[sa_scott]

Have a look at Kieranhj's scrolling sample and his ABUG talk.

I'm not sure where to find both of these - the latter I've seen a Youtube channel from Centre for Computing History, but uncertain which video precisely?

I've found Kieran's Github, but no certain which repo matches scrolling?

[fizgog]

Have a look at Kieranhj's scrolling sample and his ABUG talk.

I'm not sure where to find both of these - the latter I've seen a Youtube channel from Centre for Computing History, but uncertain which video precisely?

I've found Kieran's Github, but no certain which repo matches scrolling?

I thought the scrolling was planned for phase 2, which Kieran never got around to doing as he's been busy.

In the meantime have a look here for info

http://www.retrosoftware.co.uk/wiki/ind ... _scrolling

[tricky]

Sorry, I think it was Kieranhj chipping in about a slight issue with RichTW's pixel vertical scrolling sample of RetroSoftware: http://www.retrosoftware.co.uk/wiki/ind ... _scrolling
The timing is a bit of a pain, but can be made quite self contained - I'm sure I have posted several demos with code but can't find them at the moment and Rich is much better at explaining

[sa_scott]

Sorry to re-awaken this thread, for anyone not aware, I did a few updates to the original game, which I've put in another thread.