General games-related topics
Post Reply
dr beep
Posts: 1448
Joined: Thu Jun 16, 2011 8:35 am
Location: Boxmeer


Post by dr beep »

The boardgame SHOGUN is rare on computers.

I coded it in 2009 for the ZX Spectrum, made a port in hires for the ZX81 in 2011 (which btw led to coding 1K hires).

A few years ago someone made an app of the game which is worse than my version.

The program is 1K on the ZX Spectrum, but uses a lot more memory. I thought I would try a 1K ZX81 version.

The game is now available, but here is the story.

Code: Select all


In 2009 I coded my initial SHOGUN for the ZX Spectrum.
The program was exactly 1K in size, but the program used 768 bytes of memorypointers,
Besides that the stack needed almost 100 bytes.

If I want to fit this in 1K on a ZX81 I would need to reduce the stack, the amount of extra memory,
add a board and systemvariables. Besides that the game must load in max. 949 bytes.

A challange to give it a try.

SHOGUN is a boardgame where stones show a value of moves allowed to move.
You have 7 normal stones and 1 SHOGUN. Normal stones can show value 1 to 4 and shoguns only 1 or 2.
This is set by a magnet and a piece of iron under each field. The program must set up an equivalent of such a board. The original game used more positions so adding a crown for the shogun is easy.

If you want to do it in 1 character how do you show the difference between a normal stone and a shogun?
I was thinking of flashing, but then I thought of the "I" and "Z". You can see a 1 and 2 in it and you see a different stone to indicate it as shogun. The display of the board is solved.

The memorypointers are set to full banks, each 256 bytes. If I reduce it to used fields only I can 
reduce it to 3x64 bytes, but that is not enough.

I use 10 bits per field for information about the field. If I could reduce 2 bits I would save 
64 bytes , needing only 128 bytes for the data.

The 10 bits are defined as
uscvvvpp and ad......
u = field in use
s = stone is shogun
c = colour of player
vvv = stonenumber 000 to 111, 8 stones
pp = position value 

a = reached by human (attack on computer)
d = reached by computer (defended by computer)
A stone can be from the computer, stonenumber = 000 and position 00. All zero but field is in use.
That is why a bit is added. Like chess a shogun is placed on position 4 and 5 so the number of the stone 
is also 4 or 5, to prevent testing 2 values a bit is added when stone is a shogun.
If I use 7 stones and double 1 stone I can use values 001-111 and a used field will always have a value.
This saves the u-bit.

I also altered the start for the computer and player so that the shogun has always nr 4 as value.
Testing on 4 is now the shogun, so I skip the s-bit. Now the data fits 128 bytes.

The stack needed does a recursive search on all stones. The computer even uses the recursive routine within the routine. The old routine stacks 3 registerpairs and a return per step. Wirh 4 steps you would need 4x(3+1)x2x2 bytes for the recursion only. The intruptroutine also needs about 32 bytes. The stack is therefore minimal 96 bytes. If I can reduce 1 pair I save 16 bytes of the stack.
I altered the routine and a different approach made it possible to save a registerpair.

Although the way the program worked is copied the program itself in the end was almost fully rewritten.
The original code was in capitals, if you see the source you will see how much has changed.

Although the AI in essence is the same, I altered a few points to make it fit 1K.
In the end I was able to add an extra part in the AI.
Post Reply