what should i write next?

[Grasshopper]

Have you considered writing an AGD engine for the BBC Micro? That would potentially give BBC owners access to hundreds of new games, many of which are very good.

I've been impressed with how well most of the AGD games run on the Atom.

[tricky]

I did, but wasn't keen on the language.
KieranHJ did ported most of it to the beeb and then Kees oss003 finished it off and has been making improvements as well as porting games.
To get the most out of the BBC I find that I end up with several different sprite routines in each game and that they also change from game to game. AGD I think still uses a single routine and also only allows character based positioning which means many copies of the graphics are required - not great for the beeb.
Some games work really well and there is a reasonable variety. I don't think any of my games could be anything like they are using AGD, but I would love to be proved wrong.

[Grasshopper]

KieranHJ did ported most of it to the beeb and then Kees oss003 finished it off and has been making improvements as well as porting games.

Interesting. I've played some of the AGD games that have been ported to the Atom, and generally been quite impressed by them. But I wasn't even aware that anyone had ported some of the games to the BBC. Are any of them available to download?

[oss003]

Are any of them available to download?

The BBC port is included in MPAGD v0.7.10.

https://jonathan-cauldwell.itch.io/mult ... e-designer

You can import Spectrum tapes or snapshots, select the BBC as machine and compile the game.

BTW ... the BBC version is still lacking sound ..
Kieran also wrote a Mode1 version which converts Spectrum games into 4-dithered colours and can run small games in colour.

Greetings
Kees

[Grasshopper]

Are any of them available to download?

The BBC port is included in MPAGD v0.7.10.

https://jonathan-cauldwell.itch.io/mult ... e-designer

You can import Spectrum tapes or snapshots, select the BBC as machine and compile the game.

BTW ... the BBC version is still lacking sound ..
Kieran also wrote a Mode1 version which converts Spectrum games into 4-dithered colours and can run small games in colour.

Greetings
Kees

Thanks. I'll check them out.

[tricky]

I finally felt well enough to run the code that I wrote over a month ago!

screenshot1.png (3.79 KiB) Viewed 4488 times

No promises as the HW can draw pixels about 20X faster than a fast SW version, so it might mean replacing lots of code to make it playable - I won't know for a while!
The arcade version is four colour for most of the screen, but it uses eight for the ground area including using the extra bits to remember the ground as well as showing different colours and flashing.
This is as far as it gets without crashing, but as none of its hardware is working and I have only done a basic work-a-round for interrupts, it's surprising it gets this far!

[Rocketeer]

I finally felt well enough to run the code that I wrote over a month ago!
screenshot1.png
No promises as the HW can draw pixels about 20X faster than a fast SW version, so it might mean replacing lots of code to make it playable - I won't know for a while!
The arcade version is four colour for most of the screen, but it uses eight for the ground area including using the extra bits to remember the ground as well as showing different colours and flashing.
This is as far as it gets without crashing, but as none of its hardware is working and I have only done a basic work-a-round for interrupts, it's surprising it gets this far!

Tricky are you using the resource from https://6502disassembly.com/va-missile-command
It looks as if you've solved the problem with glyph printing, which it uses quite a lot, is that quite slow on the beeb?

[tricky]

I think that is the one that I converted.
Any pixel plotting or clearing is very slow compared to the arcade, but there aren't that many pixels plotted on most frames.

[lovebug]

ive been tempted to write a version of space firebird for the beeb but youre welcome to do it first

spin on to 9 mins 45 for game play

[tricky]

I played it a few times back in the day, but have no plans for it.
I'm currently still thinking of missile command, at least when I feel better. After that, I'm tempted to port a c64 per of an arcade game!
And then I have plenty of unfinished projects!

[tricky]

PS It would be great to see another Beeb title given some love-bug

[lovebug]

my life has taken a turn for the worst, my repair business has failed and ive lost my house and girlfriend so right now im struggling but when im back on my feet i'll write some more games

i still have joystick support to write for ladybug and an improved keyboard input to finish too !

[Rob_hawk]

That is all very sad to hear. I hope you get back on your feet soon.

[tricky]

I'm really sorry to hear that, repair of nearly anything nowadays must be very tough!

I was thinking that Mr Do's Castle would be a good one for the care and attention that you put into a port.

I was thinking of doing it bitd using MODE 2 and palette tricks to do the moving behind/in front of things, but never go around to it.

[nicolagiacobbe]

Sorry to hear that, lovebug. Hope you all the best for next job.

[sa_scott]

my life has taken a turn for the worst, my repair business has failed and ive lost my house and girlfriend so right now im struggling but when im back on my feet i'll write some more games

i still have joystick support to write for ladybug and an improved keyboard input to finish too !

Sorry to have completely missed this. Sending you best wishes. Hope things have improved for you during this time.

[tricky]

Gauntlet ?

I know I have unfinished Moon Patrol and R-Type alike tech demo plus some polishing for some of my arcade ports, but recently I've been thinking again about Gauntlet.

Gauntlet features:

1. Each map is 1024x1024 pixels, 64x64 tiles (actually 128x128 1/4 tiles in HW).
2. The visible part of the map is ~15x15 tiles and scrolls in pixels, offscreen object are dormant.
3. Each "sprite" is 24x24 and overlaps the sprite above for the not quite top down 3D look.
4. The barbarian starts by moving 1.5 pixels per frame, so 1, 2, 1, 2 etc.
5. In single player, the screen scrolls to keep the player centered unless they get near the edge.
6. Four players can play at once, the screen moves to show them all and they can't move
7. Each player has an 8-way joystick (diagonal movement is allowed) and two fire buttons, one uses magic for a "smart bomb".
8. There are loads of enemies on screen at once, max 1024 (I believe).
9. Enemies are "dumb" and just move towards the nearest player.
10. 60fps!!!

What does the beeb already have?

Dunjunz, this looks at first like four player Gauntlet, but the enemies don't behave like Gauntlet and being in separate windows, the gameplay isn't the same either.

White Magic, this looks like a single player Gauntlet clone, but the visible play area is very small.

How important are the features of gauntlet?

1. Should the maps match the originals?
2. What size should the "live" area be 15x15?
3. We can't do more than a handful of 24x24 masked sprites, but can we do 16x16 to match the spacing of the original.
4. Pixel movement speeds are OK, but how OK depends on scrolling!
5. Is scrolling feasible, not in pixels, so paging, scrolling in partial screens or show whole map?
6. Two on joysticks and two on Keyboard, but unless you are using my SEGA adapters you don't get two fire buttons each?
7. How important is the smart bomb / magic button?
8. We can't animate 1024 enemies at once, so what is a reasonable limit? (My Astro Blaster does 32 16x8 in the offscreen period).
9. Finally, something we can do - dumb enemies!
10. All of my games run at 50fps and I would like this to be the same, but all those enemies!!!

My thoughts:

1. There are something like 100 maps plus flipped and mirrored and possibly flipped and mirrored versions.
   They must have got lazy at some point and maybe a smaller number would be fine, after all, we aren't after 10ps.
2. Having a reduced area where things are "live" makes sense otherwise the entire map would just fill up.
   Maybe a slightly smaller area around each player might work 10x10 would be less than half the "cells" to worry about.
3. We could do 16x16 as the original, but might need to go to MODE 4 for speed, but scrolling is still the killer.
   What if we do what I did with Micro Rally-X and put the whole map on-screen with 4x4 sprites - that would be silly, but what about 8x8 sprites and reduce the map to 32x32 (1K min vs 4K min)?
4. If we shrink the tiles to 8x8, movement is only smooth at what would have been 2 pixels per frame before.
   This isn't too bad is it was 1.5pixels * 60fps = 90pixels/s and we would have the equivalent of 2pixels * 50fps = 100pixels/s.
5. We can hardware scroll in 2 mode 1 pixels using the HSync trick, but that doesn't work straight to LCD.
   It also requires that when going horizontally that we either blank and partially draw the edges or allow them to flicker - the main area is fine.
6. You would probably never get four players together except at an ABUG or other event.
   Four player simultaneous games are few, but fun when you have four, I think there is only Dunjunz and my Warlords port.
7. Even a joystick player would require two fire buttons, which aren't common, so can we remove magic?
   Rather than get rid of the magic button, could it be, hold down fire for N frames instead?.
8. 16x16 pixel sprites is realistically limited to 32 sprites which could probably be doubled or better with 8x8s.
   Having 8x8 sprites does save ~2/3 the amount of memory needed to store their animations, which allows more animations and more enemies.
9. Even dumb enemies cost CPU cycles to process as they still need to collide and make their dumb decisions!
   We still have to do "AI" for all these enemies and at 8x8 drawing them may not even be the most expensive part!
10. To run at 50 fps with enough sprites (64?) would require them to be drawn enmass so, no masking, no EOR etc which puts restrictions on the movement if we don't want it to look terrible!
    This leaves MODE 1 with tearing or MODE 4, double buffered with monochrome graphics!

I think I am talking myself in to 32x32 playfield, possible 32x31 + status bar or reserving the corners of the screen to always have walls where the scores/health would be.
MODE 1 would be nice as otherwise there isn't going to be much definition or differentiation in the sprites (unless you know different).
So, this would not be an exact Gauntlet clone as I don't believe that it is possible on an 8bit micro without too many compromises for me (like 10 fps).

Can interesting maps be made on a 32x32 screen?
Will it look too weird if things only happen close to the players?
Should the players still be kept in a group?
Player shots would have to be kept to their active area to stop them running away until the enemies stop and then just picking them off at range.

What do you think, would you do it differently or like to see it done differently?

Have I missed something in gameplay, optimisations or restrictions?

[TobyLobster]

I would love to see a beeb Gauntlet - it was a favourite of mine at the arcade.

I think this suggestion might go against everything in your core being(!), but it may be advantageous to relax the hard 50Hz limit? Although it is always nice to see 50Hz, Gauntlet isn't the kind of game where 50Hz is paramount. There is so much going on that I could see more feature rich epic-ness being possible at 25Hz and still being responsive.

The Amstrad CPC Gauntlet was a very nice conversion I played a lot, should be worth a look.

You don't have to update all enemies every frame of course. Update a fixed number of them or as many as you can each frame within a given time limit perhaps?

[tricky]

I'm not sure that gains much, to allow scrolling, it would need probably four or five frames or maybe three for MODE 4.
I may never get far with this one, but would like to play it
What about the 32x32 map with no scrolling?

[tnash]

Gauntlet would be mightily impressive. You need to keep the magic if you're going to keep the Death blokes in the game as they're (iirc) immune to conventional weapons

[paulb]

What does the beeb already have?

Dunjunz, this looks at first like four player Gauntlet, but the enemies don't behave like Gauntlet and being in separate windows, the gameplay isn't the same either.

I feel that although Gauntlet in the arcade and, I guess, on the Atari ST was nice in terms of having better graphics and sound than the 8-bit games, and there was a certain excitement to be had playing that kind of game with other people in the arcade, I think it is a bit of a grind and not really delivering in terms of gameplay. In contrast, Dunjunz allowed a lot more flexibility in the way the levels could be tackled, so it didn't have to be some kind of "chain gang" experience with everyone forced to stick together hacking down endless enemies. Dunjunz's levels were a lot less linear and seemed larger than they actually were.

But don't let me discourage you from anything! I just think that Dunjunz is underrated and that people get put off by the split screen gameplay, when that actually contributes a lot to why the game is so great.

[TobyLobster]

What about the 32x32 map with no scrolling?

This is all just my opinion of course: I think that a 32x32 map is still good. Scrolling feels fairly central to the original gameplay, but if it's technically impossible then either a flip or burst scroll might work (perhaps with sympathetic level design to avoid things happening just out of view?).

If on the other hand the whole map is on one screen at once then would everything simulate, move, and animate all the time? It might look weird if areas of the screen were static, and things only move around the player(s). I guess enemies could just do basic animation but not update otherwise if far away, that feels like it would work better - as long as enemies had some movement if on screen.

Yes, shots should be distance limited to avoid hitting enemies out of range, that makes sense.

Limiting to two players is another a reasonable compromise, if it helps.

[tricky]

I've never played Dunjunz, but I remember XOR being good. Is Dunjunz like a real time four player XOR? (Don't know which came first) iirc, The working title and original name for Gauntlet was Dungeons.

Synchronised idle anims would be fairly cheap and even if there was tearing, you probably wouldn't notice it.

I don't think less players helps, except you only have to balance things twice instead of four times.

As with my Micro Rally-X, the display could be swapped for one with larger sprites that scrolled in whatever way someone wanted to write.

As you will see from my Rally -X demo, I would like to see a full screen 4/8 way hardware scrolling game as well as from my R-Type tech demo, a single pixel hardware scrolling game.

My Scramble game and SMB scrolling demo does software scrolling, but only works because there is a lot of solid colour and it only Scrolls in one direction.

[Beebson]

Few thoughts about Gauntlet.

Maps were loaded in after every four or so levels on every 8-bit and loading them from the tape was fast. Should be fast on BBC too? So it wouldn´t be a problem to load every second level, or even every level from the tape as it´s fast. Using disk, even less a problem.

On Spectrum and MSX players and enemies were 16x16, I think, and both versions looked good. Weren´t their size the same on all 8-bits? Scrolling must have been character scroll on those two machines, every enemy moved 8 pixels at a time, all that was ok, at least back in the day.

Why remove magic, it´s an important feature in Gauntlet to stay alive! Death is a hard enemy without magic. Removing magic and making Death(s) easy to defeat spoils the game! There were lots of keyboard games for BBC, no? On 8-bit computer conversions, there weren´t 2-button joysticks. Using Magic from the keyboard worked well for both players.

2 players only is more than OK! Just like in other versions.

Please study every 8-bit conversions!

[paulb]

I've never played Dunjunz, but I remember XOR being good. Is Dunjunz like a real time four player XOR? (Don't know which came first) iirc, The working title and original name for Gauntlet was Dungeons.

Dunjunz is rather different from XOR. XOR is a puzzle game more closely related to Repton, whereas Dunjunz involves each player shooting the enemies, who are mostly aimless but nevertheless get in the way, as well as collecting keys to open doors, shooting traps (which reflect projectiles) to remove them, and collecting treasure, extra weapon powers, and the occasional crucifix that brings dead players back to life. The magician is the only player that can use magic, if I remember correctly. Also, and rather crucially, the viewport doesn't scroll in Dunjunz but flips between adjacent areas.

The same author wrote Icarus that had a two-player split-screen in a top-bottom arrangement, keeping certain gameplay elements such as having pass cards instead of keys (labelled so that experimentation with keys wasn't required), but adding things like forcefields that have to be disabled, blocks that can be pushed around, credits that allow the player to top up their health at vending machines, and making the enemies a bit more aggressive and also allowing them to fire at the player. Unlike Dunjunz where trapdoors were indestructable, Icarus made the robot lifts behave like the traps from Dunjunz in the sense that they could be destroyed and reflected projectiles, but they were not harmful to the player as such, if I also remember this correctly.

[paulb]

Please study every 8-bit conversions!

Come on, if you want people to do the legwork, at least provide a link to the obligatory "let's compare" YouTube video!

[tricky]

I must confess that I haven't done much homework. I have looked at videos of the other 8 bit ports and would not want to make a game like them. I don't like the compromise of character movement although I understand why it was so popular.
I probably only played gauntlet a couple of times in the arcades and the time I played it on MAME didn't impress me as with infinite credits, it seemed pointless.
I think that there are too many compromises with a version that scrolls but I will have a proper look at gameplay to ensure that not scrolling doesn't break it.

[tricky]

I've just been sketching out the sprite code and it is looking about 7K just for the code to draw enough sprites to make the game look like I would like it to. I'll try to put a demo together this week to see if I like what it looks like as it isn't going to be possible to make my first idea look good enough!

[Beebson]

I am sorry, here you can find videos and screenshots.

Arcade, NES, Atari XL, Atari ST, Mega Drive, Sega Master System, 64, Amstrad, Game Boy Advance, MSX2 (video says MSX, but it´s MSX2 homebrew, converted from MSX), MSX, Spectrum, PC
https://www.youtube.com/watch?v=5SognJgnCXc

Nearly all official versions here
https://www.mobygames.com/game/gauntlet/screenshots

Few MSX ingame screenshots, as they were missing from Mobygames
https://www.generation-msx.nl/software/ ... edia/2904/

There are conversions using 8 pixel character movement for enemies, I think it wouldn´t look bad on BBC either. If you need to use character scroll to fit the game in 32Kb, then please go ahead. With the character scrolling, it´s still Gauntlet and conversions with character scroll play really well!

[tricky]

I had looked for but missed the CGA version, which can be a good example of what a MODE 1 version would look like.

I appreciate that character movement is a good compromise but it isn't something that I will currently consider.

I'm beginning to think that this might not be a game for me.
I don't think that 8x8 pixel sprites are going to be detailed enough and I don't think that scrolling with so many sprites and complex maze will be smooth enough for me.

...

Although, maybe icons might work?
Bow and Arrow, sword, wand and Battle Axe for the players, skull or scythe for death - but then maybe it should just be character based - Ahgr!