Hihi

No screenshots or anything to show yet but I thought I'd say Hi and mention I'm working on the above...

Puzzle isn't really the right term for such games I suspect but since people think tetris is a puzzle game, it'll do

Writing it in Basic with perhaps a hint of assembly (I've found my Zaks manuals, just a case of remembering what I'm doing now, it's been a long time ;p)

For those who don't know what the game entails, it's basically a case of starting with a screen different coloured blocks and the purpose is to remove blocks in the largest groups possible, you can only remove blocks where two or more are touching (horizontally or vertically) - when blocks are removed, remaining blocks fall to fill in space, aim is to remove all of them with no odd ones left over!

Screens get more blocks and more colours as you progress through the levels...

Will probably go for a 16x16 playing area although if I can manage it, 32x32 is possible, use MODE 2 (which will give me the princely sum of 5886 bytes to work in if I want it to work on a model B with DFS so there will be quite a bit of disk loading involved!)

Any thoughts/suggestions before I get too far would be welcome, once done I will of course make it available for (free) distribution via this site if there's interest.

Yep, I know that game - although I know it as Same Game or Chain Shot!.

I've played it as KSame bundled with KDE under Linux, but the version I've spent most time with is Jawbreaker, which came bundled with Windows Mobile 2003 SE.

It's very addictive and very pick-up-and-playable. A great choice!

It would fit right in as a Retro Software title - I would put it in the puzzle game genre, and noone from these forums has come out as working on one of those, so far ...

If you'd like to record your progress on this site you're welcome to create a wiki page yourself, or we can knock up a template page for you to get you started. If you'd like a forum too, we can create you one of those - just ask.

I think you'll get a lot of eager beta-testers for this, once ppl have played it a few times ...

Sam.

A few years ago I implemented Bewejeled on the VIC-20. I've specialized a bit in puzzle/board games like Tetris, Columns, Jewels, Connect-4 etc. I suppose a big chunk of code could be reuseable, depending on how you want the game to play. In Jewels you form groups of three vertical or horizontal to remove them.

Feel free to contact me if you get to the point of reading some 6502 assembly code. Perhaps we can work together. Unfortunately I'm not yet familiar with the BBC Micro specifics, but at least I have the required hardware for second stage beta testing.

At last - a puzzle game! I enjoy puzzle games and think they really play to the BBC's strengths. I've never been very hot on arcade games.

I'll be following your progress with interest.

Excellent, looking forward to seeing this one! Puzzle games on the Beeb were few and far between, there's a lot of scope for porting more I reckon

Do you need to use all the screen though? Have you considered using a similar sized screen to Pipemania or Loopz and claw yourself back a little valuable space?

Can you use the DFS disk buffers for anything your loading from disk ? You mentioned loading so presume you load levels or graphics for a level (Sorry not familiar with the game).

If so and this data is only used when disk access is not required then you could load your level data into screen memory first (as DFS will want to use it's buffers). Once this is done (and provided you don't use DFS again until new level data is required) you then copy it from the screen memory into the DFS buffers and access it from there. Thus utilising that lost memory.

Also turn all the colours to display black when loading and you won't see the junk on screen when your temporarily using the screen as a temp buffer.

I've not tried the above but I think it's all possible. This would get you most of the lost memory back.

Highly agreed.

I spent many hours on Pipemania in both one and two player modes.
Also loved The Micro User's 'Taipei' (patience-type card game but with Mah Jong tiles) which bore up to many a repeat play with its vibrant MODE1 graphics

When it comes to memory use, I don't think the algorithms and game engine needs to take so much space. Perhaps graphics handling takes a bit of memory, but for example the Jewels game I mentioned above fits within 1 kB (no custom graphics though). I made an extended version with a flashy intro screen and background music within 3 kB. It depends a little which type of puzzle game you want to write, what algorithms and shortcuts you can take but to me more than 5 kB for code sounds quite generous.

Got a link to the Vic20 game? And a good link for Vic20 emulator on OS X?

Ta!

You can find most of my released games here:
http://www.cbm.sfks.se/cbm-software.php

For the older (2002) games, I included the source code but I yet didn't add it to the Jewels packages.

The emulator of your choice would be VICE/xvic, the same as for Un*x/Linux, Windows and so on. Worth pointing out is that one needs to go to Settings -> VIC Settings and check "no expansion memory" to get the games running. The default settings is full expansion which messes up the memory map. Otherwise I think program files even are drag and drop (at least in WinVICE).

From a programming point of view, I often rely on the screen matrix and colour memory is fully readable and directly writeable, so I don't need to maintain matrices of game data as well as the screen. I realize not all computers are designed in this way, so it might be required to allocate a bit of workspace memory for what also is represented graphically on the screen.

Hmm I downloaded vice but couldn't find that settings menu

[edit]

Aha.. Found it, need to right click, which I had to emulate with my laptop trackpad!

Had a quick look at jewels, nice work in 1K

Hihi

Thanks for your suggestions, using the DFS disk buffers does sound like an idea, was planning to load different graphics for the borders etc. between levels so it wouldn't actually need to be moved out of display memory at all and the dfs buffers could be used for workspace while playing a level

Sorry not been on in a while, had to reinstall this machine (ever notice how you never had to reinstall the OS on a beeb?) due to hardware changes and I've been working on my +3, hacking an IDE interface onto it and the like, lol, running out of space inside that machine what with a multiface, 2.5" IDE disk and now a board for the 8 bit IDE (http://www.pokenet.co.uk/misc/old%20com ... layout.gif if it's of use to anyone - 34 way connector goes to z80, 40 way one is IDE - designed from the simple 8 bit interface schematic on the +3e homepage, just discovered I'm going to entirely replace the audio circuitry too due to amstrad making a complete pigs ear of it, go figure, so got to find room for a little amp board in there too, lol)

http://www.pokenet.co.uk/misc/old%20com ... mplus3.jpg <- plus 3 if anyone wondered along with the Master and A3020 I have setup there

I will be getting back to working on this game shortly though, I'll post screenshots from beebem, seems easier than trying to take pics of my BBC running, that never seems to work very well -.o

It actually occured to me I could load the assembly routines and the borders for the levels run length encoded in mode 7, switch to tape mode and relocate them to the &e00-&18ff area leaving the basic code at &1900, that'd avoid a lot of disk loading and mean it should work on any BBC although it would mean no high score saving...

Grab your copy of 'The Advanced User Guide for the BBC Micro' and flick through to page 267. You have a lot of available memory if you are feeling the squeeze.

If you are not using sound or printer, you can be very daring and set PAGE as low as &800 (I have used &900 in a previous application). You have to watch what I/O your program requires as previously mentioned, or what frills you want to add. I have often put assembled code into the User defined key and User defined character memory when my program didn't require any of these.

Bulldozing page 13 could be problematic according to this book, I have had no troubles - My original BBC Micro User Guide shows the memory map detail with &D00 -> &DFF as 'space for user supplied routines'. (Page 501).

So if you load your huge program, move it down in memory then change to Mode 2 and do what you have to do without filesystem access you have a lot more space than would otherwise be expected. If your program is still larger than the available 9984 bytes, are there any tasks you need to do once before the mode change? Put them on the end of your program, disposable routines can go above &3000 until the mode change.

It would be nice for a game of this style to have a saveable highscore table. You also gain the ability to load new 'tilesets' when needed. (Could put your 'hires' sprites into the space &900 -> &DFF while only your program lives above PAGE). It is probably not worth the effort dealing with the scattered empty bytes in the low pages as programming for them would waste any space you gained, though Zero page &70 -> &8F are nicely consecutive for BASIC referencing if you don't program in assembler/machine code.

Hope that will help you stretch your game features.

(IDE to CF adapter + CF card instead of HDD in limited space?)

I'd be interested in seeing this. The thread looks like it's gone quiet recently. Is the developer still working on it?