Apache Valley - possible new Electron game

[rasto1968]

Inspired by my recent visit to the ABUG south meetup during which I had many great conversations I've made a very early start on something that I last looked into doing back in the mid 1980's - namely a helicopter based shooter. Tentative title is "Apache Valley". My initial thoughts are a night time mission flying down an endless and hopefully vertically scrolling valley shooting at various bad guys, avoiding missiles and picking up fuel/ammo along the way. Another option would be a Starship Command type view and maybe ditching the valley aspect - so an open desert ?

I had some spare time today so decided to see if I could get a passable animation of a helicopter in flight. Current plans are for Mode 4 as I'm hoping to have a decent amount of things on the screen and would like them to be as defined as possible - so no fat pixels and sadly no colour.

So after an hour or so of fiddling with BeebSpriter for the first time ever, here's my attempt at a 16x16 single colour Apache gunship...

apache-test-1.gif (27.96 KiB) Viewed 916 times

I've got a long way to go and judging by the pace of my other pet projects progress is going to be slow - but I've made a start. Next step is to get a sprite routine running to see what the helicopter looks like when moving around the screen - expect an update some time in 2025

[tricky]

Looks good.
Are you planning on having the other sprites that big?
Mode 4 has less byes to push around, but for 16x16 (17x16 for free if moving at 1pix). That is 3 byes wide and 5 for mode 1. You also need 8 copies for pixel movement so it takes the same memory as the for copies for mode 1. Not trying to change your mind as you still have the extra 8/10k for the screen.
Somewhere I posted the max sprites for the different situations.

[rasto1968]

Thanks Tricky.

I'm now in the great position of knowing more about what I don't know Lots to unpack from what you've mentioned above.

1. I hadn't given much thought yet to enemy sprite sizes, but I can imagine needing a mixture of pixels (bullets), small 8x8 sprites for missiles/people and large 16x16 for bigger enemies (tanks)

2. 17x16 size, this is new to me - sounds like more research is required

3. Mode 4 Vs Mode 1 - as this is an Electron game I kind of assumed that mode 1 wasn't an option due to speed issues. Much as I would like the possibility of colours, I think this game will need to be fast & smooth. I've managed to come up with a scenario that fits 2 colours - the missions all take place at night, everything looks green using night vision goggles

I will seek out your post(s) on sprite sizes and numbers of sprites.

I went down a rabbit hole of reading up on scrolling techniques and watching YouTube videos of Firetrack - I'm going to need a fair amount of playing around and tech tests to figure all of this out.

[tricky]

Sorry, I missed that it wa an electron game! From my limit knowledge, mode 4 is the right choice
My posts were about the beeb.
0xCODE has done some lovely scrolling on the elk.

[rasto1968]

0xCODE has done some lovely scrolling on the elk.

Yes, I'm hoping he will be able to provide some tech advice

I've had another idea for a game enemy - an end of level 'boss' where you have to defeat an enemy helicopter. This can just be a mirror image of the players helicopter.

Also thinking more about the game play - I might have cross hairs some distance in front of the players helicopter that show where the bullets will hit - as the gun is "air to ground". Players missiles will track enemies, but are limited in number - they can be restocked by hovering over an ammo crate.

I was thinking about having your fuel running out (restock by hovering over fuel drums) but maybe infinite fuel is a good starting point.

Similarly player damage, it might be nice that the helicopter can survive several small (bullet) hits but not missiles.

So much to think about before I've even written some code

[tnash]

I love games where the player can optionally rescue civilians for bonuses and power-ups. A helicopter game would be perfect for that.

[Cybershark]

Another option would be a Starship Command type view and maybe ditching the valley aspect - so an open desert ?

Always found Starship Command a bit monotonous. Would be cool to see something open though, with enemy bases, refuel points, objectives, etc

[rasto1968]

I love games where the player can optionally rescue civilians for bonuses and power-ups. A helicopter game would be perfect for that.

Kind of like a top down version of chop lifter then? Maybe, but the Apache isn't known for it's passenger carrying abilities

Always found Starship Command a bit monotonous. Would be cool to see something open though, with enemy bases, refuel points, objectives, etc

If I can't figure out scrolling then it will probably revert to this, but this could end up being the 'sequel' game 'Apache Desert'

[tnash]

I love games where the player can optionally rescue civilians for bonuses and power-ups. A helicopter game would be perfect for that.

Kind of like a top down version of chop lifter then? Maybe, but the Apache isn't known for it's passenger carrying abilities

I clearly know nothing about helicopters, but surely you can find room for a friendly civilian who just happens to be able to upgrade your apache with extra homing missiles

[rasto1968]

Very slow going I'm afraid I'm having a lot of issues with the toolchain and wondering if there's a better way? I'm currently using Elkulator to test my code, but the debugger isn't particularly feature rich (or there are some magic missing instructions?) In particular, I would like to be able to modify memory contents via the debugger but the help list doesn't show any commands for this?

So my question is, what are other people using to debug stuff on the Electron? I tried Mame but couldn't even figure out how to get into the debugger and the UI for loading discs etc. was much less user friendly than Elkulator.

FWIW, I'm using beebasm with the VSCode plugin for writing & building - this bit of the toolchain is working fine

[SteveF]

In particular, I would like to be able to modify memory contents via the debugger but the help list doesn't show any commands for this?

b-em has the "writem" command for this. If you are building your own Elkulator from source, it might not be difficult for you to port the corresponding change in the debugger code (roughly this function) to Elkulator. Failing that, perhaps raise an issue on the Elkulator github asking if someone else could take a look?

(Depending on how Electron-specific your code is, you could perhaps try debugging it under b-em running on an emulated BBC, if no one has a better suggestion.)

[paulb]

b-em has the "writem" command for this. If you are building your own Elkulator from source, it might not be difficult for you to port the corresponding change in the debugger code (roughly this function) to Elkulator. Failing that, perhaps raise an issue on the Elkulator github asking if someone else could take a look?

I found some debugger changes that I may not have committed, although they were possibly not very applicable generally. But the debugger certainly could be expanded to be a bit more useful. Yet another item on the list!

[daveejhitchins]

Would the Slogger Trek ROM be of any use?

Dave H.

[rasto1968]

In particular, I would like to be able to modify memory contents via the debugger but the help list doesn't show any commands for this?

b-em has the "writem" command for this. If you are building your own Elkulator from source, it might not be difficult for you to port the corresponding change in the debugger code (roughly this function) to Elkulator. Failing that, perhaps raise an issue on the Elkulator github asking if someone else could take a look?

(Depending on how Electron-specific your code is, you could perhaps try debugging it under b-em running on an emulated BBC, if no one has a better suggestion.)

I did think about this option, I'm currently not doing anything Electron specific so it's a possibility. I will have a play with b-em to see what it offers.

[rasto1968]

b-em has the "writem" command for this. If you are building your own Elkulator from source, it might not be difficult for you to port the corresponding change in the debugger code (roughly this function) to Elkulator. Failing that, perhaps raise an issue on the Elkulator github asking if someone else could take a look?

I found some debugger changes that I may not have committed, although they were possibly not very applicable generally. But the debugger certainly could be expanded to be a bit more useful. Yet another item on the list!

Given how little time I'm finding to work on this, I'd rather not get sidetracked with yet another side project that I won't end up finishing

[rasto1968]

Would the Slogger Trek ROM be of any use?

Dave H.

I will take a look at this thanks.

[rasto1968]

Took another look at my problem code tonight - and fixed the issue, who would have thought re-enabling interrupts too early could cause so much chaos!

What this has done is taught me the value of over commenting the 6502 code, I'm used to reading and understanding JavaScript without the need for too many comments but "self documenting" & "assembly code" don't really exist together. How games developers back in the day managed to do this with minimal dev tools & resources makes my mind boggle

Anyway, it still doesn't look like much but at least I now have the player sprite being drawn and some basic simulated scrolling for the sides of the valley:

The GIF looks much worse than the actual display. Next up is to add some edges to the valley sides and maybe allow the helicopter to move around a bit.

[rasto1968]

Switched over to JavaScript + canvas to see what it could look like with more "realistic" canyon sides:

animated-apache.gif (1.14 MiB) Viewed 436 times

I now see the wisdom of trying things out in a higher level language first

[0xC0DE]

Looks great so far; I hope you keep going!

[rasto1968]

And here it is running on Elkulator - to say I am happy at getting this working is an understatement - it was one of "those coding" evenings where everything just seemed to click and start working My first use of self modifying code, some refactoring that removed lots of un-needed maths by ensuring data was page aligned.

Some details:

• double buffered software "scrolling"
• the canyon walls are a single 128 byte sprite drawn with offsets

SSD to try out scrolling

scroll.ssd

GIF showing scrolling

(1.75 KiB) Downloaded 9 times

[lovebug]

very nice

[rasto1968]

Figuring out how to do the scrolling was really pleasing. One of my favourite games "back in the day" was Defender (Guardian and Gauntlet on the Electron were my go to games) and I always wondered how the landscape was drawn. At some point I'm going to have a play with horizontal scrolling (not for this game) to see if a similar technique can be used.

[davidb]

Figuring out how to do the scrolling was really pleasing. One of my favourite games "back in the day" was Defender (Guardian and Gauntlet on the Electron were my go to games) and I always wondered how the landscape was drawn. At some point I'm going to have a play with horizontal scrolling (not for this game) to see if a similar technique can be used.

If you start looking at horizontal scrolling, take a look at Moon Raider. It's quite incredible how quickly the game plays.

I think there was also a Moon Patrol clone in Electron User that had a rapidly scrolling landscape. I'm guessing other games in that style will also have used similar tricks to give the impression of a moving landscape.

[rasto1968]

If you start looking at horizontal scrolling, take a look at Moon Raider. It's quite incredible how quickly the game plays.

I think there was also a Moon Patrol clone in Electron User that had a rapidly scrolling landscape. I'm guessing other games in that style will also have used similar tricks to give the impression of a moving landscape.

I've just watched a video of this on YouTube, very impressive scrolling !

[rasto1968]

A little experimentation tonight to see how long each of the drawing routines take using the 1980s equivalent of console.log - palette switching

black background shows how long it takes to draw the canyon walls
yellow shows how long it takes to draw the player sprite (24 * 16)
blue - I run the player sprite routine again 8 times to simulate drawing other things
red - 'spare' cycles

I've started thinking about optimising the canyon drawing code as it is using by far the most cycles, switching to pure zero page could almost halve the loop time (42 cycles instead of 70) however this complicates the scrolling logic and would require some extra comparisons/branching which might end up reducing the gains - still its worth looking at I think.

I'm not sure I can optimize the player drawing much, its pure zero page with everything page aligned as much as possible.

This is fun

[Kecske Bak]

It looks fantastic so far. It's probably a silly idea, but could you save cycles on the scenery by only drawing it every other line - so it was sort of a stippled pattern?

[davidb]

You could also save time by leaving a text line or two blank at the top for score, lives, etc.

[rasto1968]

You could also save time by leaving a text line or two blank at the top for score, lives, etc.

The latest version leaves 3 lines (24 pixels) blank above and below, I made this change after seeing how much time drawing the canyon took I've also narrowed the play area a bit to balance it out, I have some ideas for things to display on the sides and above/below.

[rasto1968]

It looks fantastic so far. It's probably a silly idea, but could you save cycles on the scenery by only drawing it every other line - so it was sort of a stippled pattern?

Possibly, but I'm not sure this would save many cycles - it's easy to check though - thanks for the suggestion

Edit: Wow ! All it took was an additional INY to try this the time saved allows me to draw almost double the number of other sprites and the canyon walls still look OK to me Thanks again for this suggestion.

[lovebug]

looking great