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 626 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 146 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 2 times