Developing a new JSW-like game in C

[nw24576]

Hi,

Have been suggested to post to this forum by the guys at Spectrum Computing.

Anyway... back in the day I had a Spectrum, and later on (1994) as part of my work I learned C, and in the mid-nineties I developed a few games (mostly versions of 'standards' such as Pacman, Space Invaders, Snake and Tetris) in C (and later C++) in the DOS environment.

Have recently discovered that there is still an active Spectrum community, and having been fascinated by JSW, and JSW-like games in general, when it first came out I thought, it might be fun to develop a JSW-like game from scratch. It's something I've always wanted to do since about 1985, though I've never got round to it (and, to be honest, I'm still not completely sure I will have the time even now) but having recently found the z88dk compiler and played around with it a bit, I thought it might be interesting to try and develop it in C, though it's sure to be a challenge in the low memory environment of the Spectrum.

Have had some encouraging responses on Spectrum Computing, it looks like it's possible in theory though assembly may be necessary for the more time-critical sections. Looks like the SP1 sprite library could be useful, though maybe this uses too much memory?

The plot will not be Willy-related, though the gameplay will be very JSW-like. The plot needs to be fleshed out, but essentially you are in prison for speaking out against a corrupt and authoritarian government, your task is to first escape from the (rather poorly-guarded it has to be said) prison and then travel round the town and countryside collecting objects (which provide evidence for government corruption) and you win when all objects have been collected and you take them to a certain location. It will be JSW like in the sense that free movement from room to room will be allowed, though it may also have a Wally Week style element in the sense that specific objects may be needed to accomplish particular tasks. For instance, part of the gameplay is likely to involve collecting money and exchanging it for items (needed to win) in a shop. That bit isn't definite, though.

Anyway, the things I'd most like to ask here are firstly

a) does it sound doable in C, or mostly C with a bit of assembly;

b) if so, does SP1 sound a good plan or does it use up too much memory? and finally

c) obviously memory is in very short supply on a Spectrum, so how best to store the room layout? (I come to this below)

d) is there anyone here who would be willing to draw certain graphics? Plan is to draw my own basic ones (I'm not an artist but am probably happy with creating JSW-style graphics) and maybe 'borrow' a few I like from JSW, with credit to Matthew Smith of course - the flying pig and skipping rabbit both spring to mind - but I'd also like to feature the faces of a few well-known real world figures as guardians (I was a fan of Spitting Image back in the day), so if anyone is willing to do that, please let me know.

I have drawn up an initial plan for the room layout: I'd like to try and keep to 128 bytes per room to save space, and I think, if I make some compromises on what objects and guardians can be in a room, I can do that. The intention is to use 8192 bytes from 24576 to 32767 for the room data, and another 3K or so for the graphics (at the top of RAM, above the C stack).

My proposed room memory layout is shown below; suggestions for improvements are welcome. It's based on reading the JSW room layout to get a general idea of how it's done in JSW, rather than copying it directly.

Anyway, sorry if this is a long post, and as I said above, I am not sure whether I will actually have the time to do this... but would be good to get ideas!

Thanks!

nw24576

Bytes 0-47: blocks/platforms: (16 max per room, 3 bytes per block)

uses least significant bit = bit 0 convention

For each block or platform:

Byte 0:

Bits 7-5 INK
4 Is it a block or a platform? Will generate either a diagonal line or a block if left != right and top != bottom, depending on whether this bit is set
3-0 Graphic ID to use for block (16 possible graphics can be used)

Byte 1:

7-4 left position (16x16 grid used for positioning, so only 4 bits needed)
3-0 top position

Byte 2:

7-4 right position
3-0 bottom position

Bytes 48-71: guardians: (8 max per room, 3 bytes per guardian)
 

For each:

Byte 0:

7-6 velocity (four velocity levels, exact values to be decided)
5-0 graphic ID (64 possible guardian graphics)

Byte 1:

7-4 start x position of guardian (on 16x16 grid)
3-0 start y position

Byte 2:

7-5 INK
4 direction bit (horizontal or vertical?)
3-0 displacement to end position

Bytes 72-87: static objects: (8 max per room)
 

7-5 INK
4 is it nasty or collectable object?
3-0 object ID (16 graphics for nasties, 16 for collectables, whether to use nasty or collectable graphic set will be determined by value of bit 4)

7-4 x coord
3-0 y coord

Bytes 88-119: Room title

Bytes 120-123: Adjoining rooms

Room IDs of adjoining rooms. Special value 255 will mean "cannot move in this direction" and a wall will be drawn.

Byte 124: PAPER byte

7-4 PAPER colour for block/platform graphics (therefore, restricted to one PAPER colour per room for all platforms)
3-0 Room PAPER and brightness (brightness will be applied to non-platform objects)

Byte 125: Firecell and ladder

7 are firecells activated?
6-4 firecell ink colour, any block with this ink will be treated as firecell
3 are ladders activated?
2-0 ladder ink colour, any block with this ink will be treated as ladder

Bytes 126-127: Flags for special rooms

TBC

 

 

[IRF]

It sounds like an interesting project!

Sorry I don't know anything about C though, so I couldn't tell you whether it's feasible or not...

[MtM]

Welcome to the forum nw2! Glad you found your way over from Spectrum Computing.

 

I am amazed that IRF has so little to say about this! 😉 Given their supreme knowledge of coding! However, I am sure

that others will offer an opinion and help, I hope so anyway, as IRF say it does sound like an interesting project.

 

Keep up the good work, and welcome again.

 

[crem]

I didn't write anything for Z80 in C (actually, neither I did in assembler), but my understanding that C compiler produces decently good code as long as you are aware about Z80's limitations:

• There are no good array indexing instructions in Z80, so accessing e.g. iterating arrays by index should be avoided (the only exception is when array element size is 1 byte and array index is a signed single-byte value). Instead it's better to e.g. compute end pointer and do pointer comparison.
• Function arguments are passed through registers, so recursion should be avoided.

Sorry for another redirect, but I believe this forum should have much more experience in using C with Z80 CPU.

[andrewbroad]

Fascinating project. I too have plans to develop a JSW-like Spectrum game from scratch, possibly in the 2040s, but I plan to write my H* game engine in Z80 machine code, even though I have some experience in C from of old.

[nw24576]

Thanks for the replies. As I said, I am not 100% sure I will have the time to implement it, as I have a number of other projects on the go too - but I do hope to.  Am likely to need a bit of help on the graphics (I'm happy with doing simple JSW-esque graphics but I'm also planning on featuring prominent politicians as guardians so if anyone has skills at digitising real-world faces, that would be great - PM me if so).

Whatever the case,  it would be free and open-source software so others can always contribute. :-)

[Spider]

Project does sound like it has huge potential and I can clearly see from reading your description you've put a lot of careful thought and planning into its inception too.

Alas I know no C / C+ / C++ myself.

You mention DOS I wonder aside from any issues in writing in x86 assembly ( ! ) if there are any other language choices perhaps...

EDIT... I'm not 100% sure I know exactly what I mean myself but although I never tried it "back in the day" , if you have heard of Atmos I think it was for the Amiga a programming tool, I was half thinking a modern variant of that but not one that was too "hand holding" , something that let you deal with the quick bits via a GUI and level design etc and then do the "meat on the bones" so to speak in code directly. 🙂

Edited April 21, 2021 by Spider
Added a bit more information

[nw24576]

17 hours ago, Spider said:

Project does sound like it has huge potential and I can clearly see from reading your description you've put a lot of careful thought and planning into its inception too.

Alas I know no C / C+ / C++ myself.

You mention DOS I wonder aside from any issues in writing in x86 assembly ( ! ) if there are any other language choices perhaps...

EDIT... I'm not 100% sure I know exactly what I mean myself but although I never tried it "back in the day" , if you have heard of Atmos I think it was for the Amiga a programming tool, I was half thinking a modern variant of that but not one that was too "hand holding" , something that let you deal with the quick bits via a GUI and level design etc and then do the "meat on the bones" so to speak in code directly. 🙂

DOS is not the platform I'm thinking of developing on, but rather Linux running Z88DK and Fuse for testing. I just mentioned DOS as I did some low-level (direct screen manipulation) C programming on DOS back in the day, but it's not so relevant to this project.

Not sure if there are any other options for actually developing the game besides C and Z80 assembly (perhaps Pascal?)... would like the majority to be in C as even though I'd like to learn assembly properly I doubt I'd have the time for it right now. I do know the general concepts though so don't mind diving into assembly for small performance-critical parts. 

The only Atmos I know about is the Oric machine, released circa 1984 😉 but I guess it was an integrated development environment for the Amiga. There are certainly such environments for Linux, Windows and so on -though whether they can be hooked into z88dk I am not sure. A GUI level editor is a good idea though, and that would run on the 'host' platform (Linux, Windows...) and could be developed in such an environment.

So far I have coded up a rudimentary quick-hack level compiler in C, which takes a level as a text file (using various ASCII symbols for blocks, guardians and so on) and 'compiles' it into a 128-byte binary file in the format I've specified. It's not especially advanced and may crash if you give it bad data, but it works. Will add that to GitHub when I have a moment.

[Spider]

Ah OK. 🙂

I realised I'd made a typo but was a a long long time ago, it was AMOS not ATMOS 🙂

I do have an Oric Atmos actually , sadly no video output of any description, works otherwise! Alway classed that as the "6502 based Speccy" somehow 😮