nw24576

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.

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. :-)

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