The Map Keeper

[helpcomputer0]

These are a few mockups I made for a simple 1-bit RPG, just playing around with something I could manage to make in BASIC. I might add more ideas here later or prototype something eventually.

Ideas so far:

• You are a spearman
• Ride around a fantasy landscape
• Visit villages and castles
• Explore dungeons
• Increase your valor (this should be important)
• Find the map keeper

Obviously it's quite derivative but it's still a basic idea right now.

This great font is by Damien Guard: https://damieng.com/typography/zx-origins/scribe/

[R-Tape]

It shouldn't come as a surprise that you're good with UDGs too! It looks great, the bottom left forest scene especially. The b&w looks classy, but did you try colour?

[helpcomputer0]

It shouldn't come as a surprise that you're good with UDGs too! It looks great, the bottom left forest scene especially. The b&w looks classy, but did you try colour?

I'm resisting the temptation to add colour! I think it might also take something away from the aesthetic.

[4thRock]

A very simple colour scheme might work:

[helpcomputer0]

A very simple colour scheme might work:

It has some nice parts to it like the trees and water and helps visibility in the dungeon, but as I was saying on another platform, it feels like feature creep to add colour. I'll do some more testing.

[helpcomputer0]

Kinda settling on these colours for now, welcome any thoughts though.

I want to try and keep it as if its all written on paper, so thats why I've made the dungeon the same light background.

[ParadigmShifter]

Mountains should be purple shouldn't they? After all it's in a hymn

The purple headed mountains
The rivers running by
The sunset and the morning
That brightens up the sky

No sniggering at the back of the assembly Finbar!

Maybe do the rivers with cyan ink on blue paper, how does that look?

Basic is going to be an issue though but if you have a good idea and need some ASM I might be able to help (once I've finished my existing project).

[g0blinish]

Looks beautiful. Once upon a time I wrote an 8x8 font editor and added the option to draw on a map

[TMD2003]

No sniggering at the back of the assembly Finbar!

We'll see about that!

Code: Select all

1 LET r=INT (RND*8)+2: RESTORE r: READ c: FOR n=1 TO c: READ a: PRINT AT 0,n-1;CHR$ a;AT 1,n-1;CHR$ a;: NEXT n
2 DATA 6,70,110,97,114,114,33
3 DATA 5,83,112,97,100,33
4 DATA 4,89,105,107,33
5 DATA 4,78,111,112,33
6 DATA 5,83,110,105,116,33
7 DATA 7,70,117,114,98,105,116,33
8 DATA 4,65,114,102,33
9 DATA 5,67,104,111,116,33

[helpcomputer0]

Mountains should be purple shouldn't they? After all it's in a hymn

No sniggering at the back of the assembly Finbar!

Maybe do the rivers with cyan ink on blue paper, how does that look?

Basic is going to be an issue though but if you have a good idea and need some ASM I might be able to help (once I've finished my existing project).

What issues do you foresee with BASIC?

I can see scrolling being an issue maybe, these are the modes where I've tried to minimse scrolling/redraw:

• World Map - Redraws the map after a certain number of moves away from centre in either direction. Probably 6-10 tiles.
• Local Map (Castles and villages) - Static, one screen only.
• Dungeon - Flip screen.
• Combat - undecided but likely a small popup. Only occurs in dungeons.

[ParadigmShifter]

A prototype might be ok in basic I suppose especially if it is turn based.

Maps might use a lot of memory unless you run-length encode them (e.g. 14 tree tiles followed by 9 spaces, etc.). You might want 2 types of run length encoding as well for (N tiles repeat horizontally and another one for N tiles vertically. You could also do NxM blocks of the same tile as well). Build screens by setting all the background to one tile type (plains probably or maybe brick walls in a dungeon and carve out rooms) then build the rest of the screen from data.

You'll want to use a string for the display and collision detection I expect (don't use SCREEN$ that's real slow) and don't use numbers either (5 bytes a pop) unless you POKE them into memory and PEEK. I'd recommend a string (either a single string width*height in length or an array of strings one for each row).

Building the strings from the map data might be slow though. If you don't build them and have your strings already initialised each screen will be width by height bytes in length (your screens look to be 30 columns by 17 rows = 510 bytes if you do that + any array/string definition overhead). Pretty sure basic stores the strings in the program then when you create a string copies the data so each screen would use double memory I think?

Unless you do it on a version of basic that gets compiled on the PC to Z80 code in which it probably will be fast enough.

If it's turn based and all enemies/NPCs move at the same time as the player (like in a roguelike) it will chug in Sinclair Basic though as you add more moving entities.

Character cell based games are surprisingly easy to do in ASM though. The ROM calls to print a character are really slow though (I was trying to do that from ASM the other day, had to rewrite what I was doing because it was too slow!). The 2x2 graphic characters are stupidly slow to display (which is what I was trying to do) - it builds them in memory programmatically on demand when you want to display one lol.

[helpcomputer0]

...

Thanks for the response. This makes me sad, there are a few things I wanted to do on top of what I've already posted but it's not gonna happen in BASIC that's for sure. Not unless I cut a lot of stuff.

I do know C, so maybe I can use one of the Z80 cross-compilers or get some poor soul to do the programming for me

I'm still designing and prototyping the game in another engine anyway, so there's work left to do.

[ParadigmShifter]

Have a look at z88dk then if you know C.

https://z88dk.org/site/

which has been used to create a lot of games (Mojon Twins and maybe Alessandro Grusso uses that too?)

I could code some ASM to draw a static screen given the data for each of them and make the data format easy enough to understand so it can easily be modified. I'd recommend the run-length encoding format since that is easy to understand how to build screens and it requires no complicated decompression or anything, and saves a lot of memory if there are blocks of contiguous tiles of the same type.

Not going to write a tile editor for you though

Although I too am also busy coding something else at the moment, but it shouldn't take too much time to finish that off.

EDIT: If you want a really big outdoor map (say like Lords of Midnight size) and can limit it to 16 tile types total the easiest way to do that is to store each tile type in half a byte. You can also use a special "override tile type" data type if you want more special locations/tiles etc.

[spotlessmind1975]

it's not gonna happen in BASIC that's for sure.

Have you tried looking at ugBASIC?
It is also for ZX Spectrum, and natively integrates a tile engine that supports Tiled.
If you use Windows it has also an handy IDE.
In my opinion it is worth trying, to see if it can give you a way to write the game remaining in BASIC.

[patters]

Just dropping in to say I really liked the black and white mockup, more than the colour ones. Maybe retain a b&w option?

[helpcomputer0]

Have a look at z88dk then if you know C.

https://z88dk.org/site/

which has been used to create a lot of games (Mojon Twins and maybe Alessandro Grusso uses that too?)
...

I did want to keep it old fashioned and do it all on a Spectrum (emulator) but it's more punishment than it's worth.

Have you tried looking at ugBASIC?
It is also for ZX Spectrum, and natively integrates a tile engine that supports Tiled.
If you use Windows it has also an handy IDE.
In my opinion it is worth trying, to see if it can give you a way to write the game remaining in BASIC.

ugBASIC looks really interesting and compiles into assembly. I might try it out, thanks!

Just dropping in to say I really liked the black and white mockup, more than the colour ones. Maybe retain a b&w option?

I've grown fond of the colour one now. What if you just turn off the colour on your emulator/TV?



Doesn't look bad, maybe even better than pure B&W?

[R-Tape]

Within reason, I'm struggling to find a colour combo that I don't like. I've a slight preference for the classy monochome (INK 0 works really well with PAPER 7,4,5 and especially 6 IMO), but your colourful version has pure Speccy feel. Short of using PAPER 3 INK 4, I don't think you can go far wrong here, so I reckon you should pick your own favourite.

[Bedazzle]

ugBASIC looks really interesting and compiles into assembly. I might try it out, thanks!

Same does Boriel
https://zxbasic.readthedocs.io/en/docs/

[ParadigmShifter]

If you know C I'd still recommend z88dk because Basic as a programming language is kind of bad. (In my opinion of course).

Although both compiled basics mentioned here look far better than Sinclair Basic (no line numbers but have procedures, better control structures, etc.).

I'd still rather program in C than Basic though. (I do all my development on the Speccy in pure ASM though - but I may prototype something in C or C# on PC then convert that into ASM for use on the Speccy). I program in ASM on the Spectrum because programming in C would be too easy - and even in C if you want max speed (for Z80 anyway) you have to use inline assembler for some tasks EDIT: But prototyping without any ASM is fine. EDIT2: Debugging on an emulator is probably easier in ASM as well unless z88dk emits source line level debug info (and if the emulator debugger supports that - probably not!)

C is the de facto lingua franca of coders really, and once you know that you can easily move on to C#, Java (yuk) or C++ (yikes). Even Javascript (what a curious language that is, but it's everywhere now).

I wouldn't recommend what Bjarne says and learn C++ before C. I think Bjarne has a secret agenda

C++ is powerful and all that but it's way too easy to write unreadable code that no one understands how it actually works unless you are VERY careful and know what you are doing. The C++ standard library is nice though I'll give it that. C# is missing some nice algorithms and containers from the base library (e.g. priority queue, next_permutation, stuff like that. Of course libraries for anything you might need are available though).

[spotlessmind1975]

Same does Boriel

That's true, but ugBASIC also has one more thing. It manages tilemaps natively. In other words, you can draw a tilemap, like the beautiful ones that we are seeing here, using an handy open source tool like Tiled. Then you can draw (and scroll it) it on ZX Spectrum with just two instructions:

Code: Select all

    map := LOAD TILEMAP("map-keeper.tmx")
    PUT TILEMAP map FROM 0, 0

There are also instructions for exploring / scrolling the map you are seeing at that moment, or drawing single tiles / element of the game, but in short they are all things that make writing games of this type a bit easier.

C is the de facto lingua franca of coders really

Yes, you are right.

The main problem in using C on 8-bit processors lies in the fact that this language (like most others) relies heavily on the use of stack: with the stack you pass parameters to functions, on the stack you allocate variables, and so on. The stack is an overall expensive resource -- much more expensive, for example, than accessing memory directly. So much so that most optimizations in 8 bit cross-compiler C consist of... not using the stack! How? Using global variables, for example.

There are some languages, such as ugBASIC, that were created specifically to program efficiently on 8-bit processors. Unlike the C language, this language is "stackless". This approach, in addition to allowing you to write very efficient prototypes, allows you to write multitasking programs with dozens of threads on ZX Spectrum. Multitasking programming allows you to write simpler programs because the logic for each "task" in the game is in a separate procedure.

[ParadigmShifter]

Yup I know why C is slow on 8 bit processors, which is the main reason I program in ASM on the speccy. (also debugging as I mentioned since what you see in the debugger is what you wrote).

Does ugBasic not support recursive functions then if it does not use the stack if it can help it? Or does it only not use the stack for parameter passing (again, recursion can be an issue then if you use global variables unless you use a heap).

I also try and avoid using index registers unless it will actually make the code faster (usually it doesn't). I'll sometimes use IXH or IXL say if I have run out of registers and it would be faster than either PUSH / POP of another register or reading from a global variable (LD IXH, reg is 8T vs. 21 for a PUSH/POP pair. Also faster than using A' (2 EX AF, AF' required)). I'll also use self-modifying code if that will make code faster (or smaller- because I use a ton of macros ).

Menu and UI code I don't mind using IX and IY though since speed is not so important then.

EDIT: I guess you picked Basic as the syntax for ugBasic because many people interested in retro coding will have used Basic originally then. I'd prefer one with nicer syntax though Something like Python (or C - although that can be hard to parse I guess, and some of the operator precedents are messed up - but everyone knows that now so we're used to it and changing it might cause unexpected results).

EDIT2: Anyway a bit off topic this. Maybe open another thread to talk about 8 bit HLLs vs ASM

[helpcomputer0]

That's true, but ugBASIC also has one more thing. It manages tilemaps natively. In other words, you can draw a tilemap, like the beautiful ones that we are seeing here, using an handy open source tool like Tiled. Then you can draw (and scroll it) it on ZX Spectrum with just two instructions:

Code: Select all

    map := LOAD TILEMAP("map-keeper.tmx")
    PUT TILEMAP map FROM 0, 0

...

These kind of things are a huge plus, and I regularly use Tiled in other projects too.

My only issue with ugBasic so far is there doesn't seem to be that many games made with it which makes me question it. Maybe I'm not looking in the right places or it's still fairly new.

[ParadigmShifter]

I think z88dk has a tile drawing engine, not sure. A lot of tile based games certainly use z88dk though.

z88dk has a library with the optimisation that it only updates things on screen which change position as well I think? It was where I got my idea to dramatically improve the speed of Manic Miner from (unfinished but playable - some said it was too fast! It probably is!). You kind of need a backbuffer for that though. (Not that I'd do it in the same way today - I'm drawing directly to the screen, and while I do only update things which change position I use a list of things to erase and draw instead of a backbuffer).

EDIT: My unfinished Manic Miner (all levels are present and correct). It was my first attempt at ASM coding on any platform

https://spectrumcomputing.co.uk/entry/3 ... iner_Turbo

[dfzx]

EDIT2: Anyway a bit off topic this. Maybe open another thread to talk about 8 bit HLLs vs ASM

Given the misconceptions about z88dk that are flying about in this discussion, that might be a good idea!

[ParadigmShifter]

Go for it if you want.

I've never really looked much into z88dk (I have played some Mojon Twins games though which were made with it, dunno if they wrote their own tile stuff or if it is a lib from z88dk they used to make their engine), those were good.