I was driving on the highway (which by the way I do every day for my job)
as I passed a broken truck tyre. That tyre was replaced by a new one.
I immediately was thinking on F1 and a pitstop. How quick 4 tyres are changed
by 4 teams. Then I thought of a way to play all teams within the same timeframe.
I once made a game that recorded moves and could replay the moves.
It was my 1K version of CHRONOTRON for the ZX Spectrum. That idea could be used
on this game too. Play a team, go back to start, play next team untill all teams are done/
The name was also in a flash there: MAX VERSTAPPEN FORMULA ONE PITSTOP SIMULATOR.
The name would be so long it wouldn't fit 1 line on a ZX81.
I repeated the name several times. The name itself mad me laugh about the whole game to come.
This one is the craziest yet and now I have got the hang of it (best time 6.06 ) I am really getting into it.
Looks good in inverse video on real zeddy and also plays much better on the real thing than in the emulator.
Like I said the subjects you choose really make the 1k world fun.
There are 16k games that are not as much fun as these.
This is a step in every game. I developed a tool in EXCEL to
create the graphics and translate it into data to be coded later in the game.
Besides the graphics each game need a way to display the game. Almost each game
has a routine defined for that game. This game is not different.
Displaying the car is easy. Each line add 5 to the display. The tyres must be taken off too.
This is solved by counting the lines. The first line, the fourth and the the last four are relevant.
In the display you can disable a byte. The tyre is still in the data but the display is disabled.
After line 4 the display is set back on to display the car. I thought the car could be 4x4 but that was
too small. So I added another column, making it 4x5x8=160 bytes of data.
The graphic of the arrow is just 4x8 for each direction.
I had a person hands up indicating waiting for Max to come in, but I didn't like the graphic.
In the end it just became a space.
After defining the routine it needs to be coded. This is always a tricky moment.
Does it work on screen as thought on paper? This routine is quite simple.
At the start: do I need to set display of the wheel on/or? If not just wait. If so do.
Then display 5 bytes, go to next line and wiat until line is filled before doing the
next line. Still it is nice to see the first correct display.
I wanted Max to drive in fast and then slow down and accelerate out.
I also wanted a 2 pixelmovement. I started with the driving as it is.
If I would heve room I could add that later. Ths driving is done as my first game is coded.
It has delay before and after the display of the car. The display in front is increased and
behind the car decreased with the same time. This will move the display of the car.
Suggesting the movement of the car. The driving is cut in 2 halfs. First to the stopplace
Second after tyrechange to drive out.
So now we have Max driving in and driving out. It is time for the gameplay
I had the delayroutine for the driving hardcoded. This routine can be coded in less bytes
and rebuilt by the program. It is just 32 NOPS and a RET. I made a routine to built
that line out of code at the end of the memory. This will save bytes and the place where it is built
can be reused for stack. To play a team I needed to show the arrows. To the screen I added the displays of the teams.
Both sides. The routine is the same only once above the car and once below the car.
To play a team is just showing the key to press, record time untill right key is pressed long enough,
store time past, show new key, repeat until end is reached.
I have 4 teams, 6 stages of the changes
1) You must press no key, you can't start before car has stopped
2) Press the wheel off key (up above, down below)
3) Press the wheel out key (left or right)
4) Press the wheel in key
5) Press the wheel on key
6) Step aside, do nothing, car can drive out
So I decided to store the time passed per team in the first 24 bytes of the system variables.
This space (36 bytes total) can be used after loading. A table of status of each team would be elsewhere.
The first team could be played and recorded, but is the recording good enough to replay?
Adding next team is just adding a loop with a counter in a register.
After each team the counter is increased until all teams are done.
Another register controls if the displayed team is the team you play or the computer.
The playing worked.... as shown in chapter 5. But how was the recording?
After playing the first team playing the second team worked ok.
Replaying the first recorded team took longer than the actual recording, so whatb was wrong?
Glancing through the code made me realize that the recorderregister was not reset after storing he
previous fase. This made the second stage the sum of stage 1 and 2 and on it went.
Resetting the recorderregister made the replay as it should be.
But why didn't the endtest of each team work?
The endtest was done by checking if each team reached step 6.
This was done by getting the status of each team and subtracting 6 for each team before that team.
This needed a variable counter for each team to determine the right status and it just didn't work.
The solution: make a recordingbuffer of 8 bytes for each team. This would cost 32 bytes over the systemvariables
but heay, we had 36 free so no problem. The advantage to this would be that for each team the same check can be mad.
Just keep the 3 lowest bits with AND 7 and check the value 6 (endstatus).
With this fix gameplay worked.