Norman Sword

Amstrad version of Jet Set Willy 2. The Amstrad(CPC) version of Jet set willy. Was written as Jet set willy, where the programmers decided to fix the weird layout of Jet Set Willy. By adding some extra rooms into the gaps of a neatly planned layout of jet set Willy. From the outset of writing the game on the amstrad(CPC) it was decided to use a very simple run line compression. The compression was added to a room designer written on the CPC. This was written in a few lines of basic. Each designed room was then output in compressed form. As a set of data statements and sent via an RS232 link. The RS232 link was via a z80dart connected to the CPC. The receiving Machine was a Tandy model 4. All rooms received by the tandy model 4 from the CPC were of the compressed data. Any room that needed to be edited was either re-drawn or the compressed data was hand edited. This data and the code that was written for the cpc was the basis of the version released on the Spectrum called JSW2 the final frontier. The room data is an exact copy of the CPC data with editing of that data to change the way the spectrum uses colour compared to the CPC four colours. At a later date. After JSW2 was released on the zx spectrum. A need arose for the CPC to have a version that was more inline with the other versions of JET SET WILLY e.g. only had 60 rooms. This was necessitated for the release of "they sold a million" compilation tapes. Which had been released on other machines, and a version was planned for release on the CPC. For the "they sold a million" version on the CPC it was decided to remove all the extra rooms and leave the game with only 60 rooms. This later version on the CPC was released in the compilation "they sold a million" on the CPC. The net result is that the data for both CPC versions are very similar to the spectrum version of jsw2. And all are compressed with that simple run line encoding. Written in a couple of lines of CPC basic.

VERSION 0001.0 This is a full game based on the continuation of the story FULL SCREEN GAME PLAY ----------------------------------------------------------------------- All version have been replaced by the latest version ----------------------------------------------------------------------- 1st version MP_0001.TAP - 10 downloads 3 basic versions of play, immediately available 1) Trainer mode - lots of air and allowance for sprite contact, nasty contact and falls. Very slow air depletion - no end game 2) Normal mode - fixed amount of air and allowance for sprite contact, nasty contact and falls. Moderate speed air depletion - game can be completed to end game 3) Expert mode - very little air. Just enough to finish a cavern. All contact and falls kill. Very rapid air depletion.- game can be completed to end game 4) ACE mode - only available after completing the game in Normal or Expert mode. Faster air depletion than ACE - no time to look around Each mode has its own high score --------------------------------------------------------------------------- 2nd version is Mp_0001C.TAP - 10 downloads This is basically the above game with a final end of game bonus Bonus end game bonus 1000 for each life in Normal 2000 for each life in Expert 3000 for each life In ACE --------------------------------------------------------------------------- third version was MP_0001T,TAP - 7 downloads This was an expansion exploring the dark light basic concept. This version takes the original idea and expands into a playable version. The two extra options, lantern and candle are playable. The lantern version more so than the candle version. The biggest challenge will be the inability to see the solar light beams. In the candle version the clock stops when ever Willy stops moving. In Lantern and Candle version the beam of light can be rotated when static using the keys "H" and "K" for one direction and "J" and "L" the other direction. Due to more options available in this technical demo - the end game bonus is also increased. ---------------------------------------------------------------------------- Version 4 Mp_v12.tap --- 5 downloads Fixes several design quirks. Modes of play 1) Trainer mode - lots of air and allowance for sprite contact, nasty contact and falls. Very slow air depletion - no end game 2) Normal mode - fixed amount of air and allowance for sprite contact, nasty contact and falls. Moderate speed air depletion - game can be completed to end game 3) Expert mode - very little air. Just enough to finish a cavern. All contact and falls kill. Very rapid air depletion.- game can be completed to end game 4) ACE mode - only available after completing the game in Normal/Expert/Lantern/Candle Faster air depletion than ACE - no time to look around continuation of modes - the following two modes incorporate a beam of light from Willies helmet lamp 5) Lantern mode - same time as Normal. background is blue-ed- allowance for sprite contact, nasty contact and falls. Moderate speed air depletion - game can be completed to end game 6) Candle mode - same time as Expert mode - background is blacked out. clock stops on no movement. All contact and falls kill. Very rapid air depletion.- game can be completed to end game Rotate the light beam in Lantern/Candle by pressing "H"-"K" or "J"-"L" when Willy is static Each mode has its own high score Since this incorporates every change that has been written into the above separate versions. Those old versions have been deleted. 1 fixes blue-ing of the portal when passing in front in candle and torch mode. 2 increased compression of data. 3 added an on screen version number on the title screen. 4 updated the light rotate on torch mode. Forces beam change on static turn. 5 numerous small changes. 6 changed title screen animation. ---------------------------------------------------------------------------------------- and for the observant a possible update which only affects candle mode Version 4 Mp_v13.tap mp_V12.tap mp_V13.tap

All room times set :- I should play through again but I am not that willing. Speed factors set as 8 - 6 - 4 and trainer 3 ACE MODE The speed setting of 8 gives just enough time to finish. It is the time taken by me plus a few air bar segments .Since the air bar is progressive in nature. A few segments can be as many as a hundred frames. Instant death if touched. This speed option is not available until the game has been finished once in normal or expert mode. EXPERT MODE based on the ACE MODE. This mode gives around 20% more time. This mode can be selected from the start. Instant death if touched NORMAL MODE based on the ACE MODE. This mode gives around 30% more time. This mode can be selected from the start. Permits the occasional touch. One less sprite in the room TRAINER MODE based on the ACE MODE. This gives around 100% more time. Which normally gives a lot of time. This mode can be selected from the start. The air bar is always set to full for the start of any room. In Later rooms the setting to full is not as big an advantage when the air bar needs to be set to a high level anyway. This mode permits quite a few touches in early rooms. Also less sprites to block path and slow progress Each mode depletes the oxygen bar at a different speed. The Maths involved in the time taken is skewed slightly (deliberately so) to adjust the times overall. This has allowed me to set the highest possible air bar in difficult rooms. Otherwise the full height of the air bar would never be needed and the changes in speed between the various levels becomes too great. --------------------------------------------------------------- Final game version accessible via This Link

I have other things to do at the moment. Which will stop any further looks or comments on this.

I ran one of the versions listed above. I modified the file by changing one instruction from LD (HL),L to LD (HL),B. The original opcode is used to wipe the attributes, the changed opcode just sets them all to BLUE ink. This one byte change allows you to see the method used to draw the area illuminated by Willies head lamp. (allows you to actually play the room- within the limits of what the change in code does) Note no other change was undertaken by me... What you see is how this program does the illumination. dim version.szx has the cheat already activated dim 2 version.szx does not have the cheat activated ---- With the mods Note change from dim2 version.szx to dim 2 version .szx ADDENDUM The poke is Poke 37733,112 - Changing the value from 117 to 112 - changing the opcode from LD (HL),L to LD (HL),B The poke is Poke #9365,#70 - Changing the value from #75 to #70 - changing the opcode from LD (HL),L to LD (HL),B dim version.szx dim 2 version.szx

Example of two of those routines . The big graphic showing duplication of tiles. 2nd picture showing the tile linkage. And Overwriting the lower status area the game cycle counter and the collisions so far plus air bar value (meaningless when shown in trainer mode)

The time between pressing F9 to assemble the program and pressing F10 to run is less than a second. It is very easy to have a variable that specifies a start room and jump the game into that room. It takes no effort to assemble and play doing any room. The program does have built in, beside the timer display routine, some other routines. When designing a room we have 16 tiles to play with. The game control uses the colours to assign to each tile a purpose. So we can have conveyor floors or conveyor walls, or even conveyor nasties. So when designing a room and assigning the colours. I needed to be able to see what tile has what property. e.g. Have I duplicated a colour. So I wrote a routine to display the tiles and their usage. The routine draws each tile as a graphic in a big square on the screen. For every graphic it scans the playing screen for the usage of that graphic. Then it scans all the other graphics to see if any graphic is defined in a similar colour. If it finds another graphic with the same colour. It places a marker on the screen to show the graphic colour duplicate. It then re scans the playing screen to see if the duplicate colour tile is also used. It then marks it as a duplicate and used and not just a duplicate and un-used, which can be ignored. (just one of the multitude of routines, that has been written. But will never be seen) The music debug routine (in addition to the placement on the keyboard) shows numerically the note position in the sequence, the note, its octave, the note length and the note value eg. F# --- again never seen. The game timer shows the current game cycle and the number of death contacts - not seen The initialisation routine checks memory overflows during compression and program overflow - not seen --------------------------------------------------------------- Final game version accessible via This Link

Even though it might appear as if nothing is happening. I am still adding bits and pieces, and changing what happens and how it happens. The routines are scanned and have to pass my criteria on what is acceptable. For example the game completion routine has an addition of data added to the display, it now plays three sequences of noise/music. The two tunes at the start were re written, the music routine was changed and extended. The room order is slightly different, one more room added. The sound effect from touch was altered to have more impact from touch. The original made a sound which did not impact on play. (e.g. it was not really noticeable) touches and falls now impact on play. Playing through all the rooms. Undecided if I go back to the original timer settings. The reason being that in expert mode, the time as now set, which will be based on how long it takes me to do a room, is far too lenient. Giving some figures for the number of frames needed to finish a room. Room1-102, room 2-377, room 3-629, room 4-613, room 5-1263 ------- room 8-1479 . If I allow 50% extra time on room 8 that is 700+ frames enough time to finish room 3. The three levels of play are trainer/normal and expert. Hardly an expert if it takes an extra 700 frames compared to me. Put another way. If i can run a mile in 4 minutes, then an expert is not going to run a mile in 6 minutes, and the normal runner in eight minutes. far too much leeway. Notice I left the trainer mode out of that list. The trainer can run the mile in around an hour. What I am doing at the moment is playing each room to completion. And taking a note of the frames to completion. (where a frame is a complete game cycle and not a 1/50th sec video refresh cycle). I will decide at the very last instance what speed the game is set to. I have added an extra room, this is done by compressing the game data. I have done this in a convoluted method. Explanation to follow. Room compression:- Manic Miner has no room compression. JSW has a 2 bit steam compression. Manic 40 Miner uses a simple 4 bit stream compression, that enables editing in hex nibbles. Manic Panic . Starts with a 4 bit stream compression . e.g. nibbles It then takes the stream of nibbles and expands the data out into bytes containing one nibble each. the Data in the lower nibble It then takes the stream of bytes each with one nibble of data and compresses into a repeat count bit stream of nibbles. It stores the repeat count bit stream of nibbles. Then discards the original data. This allows the original rooms to be edited as hex nibbles and not the awkward repeat stream of nibbles. The program also allows the definition of willy to be edited, the program will then generate the mask needed to play the game. When the game is run... the routines listed above will be overwritten. --------------------- Doing all this on my own, with basically no reason to do so. Means I am not pushing to finish this. By the end of the week I should have set all the rooms to completion times. -------------------- --------------------------------------------------------------- Final game version accessible via This Link

academic... His legs are not tested for the collision, only his upper half. The amount of sideways movement for the upper half passing through a switch would be considerable. supposing he jumped sideways at a switch. intending to land on it. The switch platform is either one or two characters above his feet. normal arc of passage would allow the sprite to effectively move sideways after missing the platform (switch) and his lower body would move effectively 4 pixels sideways before the upper part of the sprite is registered as being in the switch square. On a switch block one char higher than his feet. if the switch was was two chars higher than willies feet then Willy would move effectively six pixels into the char. ----- Not a trivial amount. The area that would now be checked for pixel collision with the switch would be the area around the middle of Willy. The original comment about collision was an instantaneous off the cuff remark.

The arc of fall does not always land on a block (When it has a side component). Think how often you jump trying to land on a platform, and watch Willy pass through it sideways. I was expanding the passage of sprites through movement. Agree that standing on a switch is possible. I am surprised that the switch has managed to progress so far, without it being a problem (to me). Skylab was written first, light beams second, and for no particular reason Kong was written last. The problem encountered when producing routines is the consistency of how you self test them. No matter how much you try to vary the way you test a routine. It is not the same as the real world. I wrote a short game program that contained a space ship that fired a gun. Never crashed in the month I ran it. Someone else came along and crashed the game pretty much straight away. Baffled I asked the person to crash the program again, and they did. What that person did was switch the auto fire on, on the joystick. This sent the program constantly into a subroutine which did not handle the stack properly. The auto fire kept adding junk to the stack and over the space of a few minutes the game crashed. Yet all the time the game was being displayed on the screen, there was never a reason to fire a bullet. When the firing sequence was needed and bullets fired. The game reset the stack. I did not expect someone to just fire the gun, because he could. The above was pretty much the first routine I had ever written, a couple of thousand lines of code, and it taught me quickly to keep track of the stack. Short cuts must abound when nasties sap a plentiful supply of air. All the screens with spiders dangling from webs. Just walk through the web and jump. No worse than using rollback and playing via that method. My other half used to play hidden objects games. I bought about 100+ of the games and gave her access to them. Halfway through the 100+ games, she stopped using a pc completely and moved over to an android smart phone. So I had a mass of unused games. They were never even download and existed unused for around 10 years. Until two months ago, I down loaded one of them. (around 1 giga bytes) and played it. Great graphics, nice tune. Yet in a lot of circumstances I had no idea what was expected and I spent the weeks just clicking the hints button. Most of the game puzzles were easy enough to do, but some words do not translate well across the pond. The hints button would keep highlight something, where that the american word, to me, was obscure. Or indicate an object where the correlation to another object was vague . I finished the game having played (clicked on hint) it all the way through. Not tempted to go back and play again without the hints button, but I suppose the constant "hints" is just another form of cheating. Therefore in Manic Panic I now class jumping on and passing through nasties, as just using the games hints. (Now without the jumping on part) --------------------------------------------------------------- Final game version accessible via This Link

The wording I used, Is falling into a switch. Not walking into a switch. --------------------------------------------------------------- Final game version accessible via This Link

Completed and minus the final music - and some other changes, like the cold room and the trivial death switch change ----------------------------------------- With such a low score overall. I need to increase the Bonus for Kong's demise. ---------------------------------------- I now need to do what you have done, to completion with the room timer activated. From the time taken to do each room the oxygen bar will be set. The original oxygen level was going to be set as the speed I can do it + a little extra. The title is Manic Panic. Having very little lee way in the time to complete a room was the general idea. Since the speed of the clock/oxygen has been changed to run at differing speeds, I will set the timer for my run, Which is clocked at a speed factor of "6" Expert will be clocked at "4" , giving a lot of time over my run Normal is clocked at "3", giving twice the time over my run Trainer is clocked at "2" which even if the oxygen was not set to maximum, would give three times longer than my run. ------------------------------------------------------------------------- --------------------------------------------------------------- Final game version accessible via This Link

I stated writing this just after my last comment.. I have watched a few tv programs since and noticed other replies, whilst this was being written. So I assume detail overlap --------------------------------------------------- Very difficult to track a problem in active code. I would normally write a big stack of debug routines to track the problem. I looked at the code layout and thought of a far easier way. Just re organise the routines. Even though both master and working screens are updated, the problem I would think is a pixel collision problem with the switch. Willy has punched a hole for his sprite. the switch is updated into the hole. The casual comment he can jump the other way would seem to indicate pixel collision, occurring due to different pixel combinations overlaying the switch. E.g. Willy detecting the pixel change and killing Willy. Willies sprite is preceded by a lot of blank pixels, no matter which way he moves. It is only jumping/falling that permits the sprite to enter a square in any phase of animation. A re organisation of the code is just moving one line of code... Far easier. Done and seems to stop the problem. ------------------------------ The best way of describing the above problem. When Wiily jumps his arc goes 4,4,3,2,2,1,1,0 etc. the first part 4,4 we move up one Char, the next part we move up one char with the 3,3,2. And finally we move into the square above by two pixels. Those two pixels are the top of willies hat. The switch is updated and changes the lower three pixels of the switch. If and only if Willies hat (lamp) is/was in this area , then we have a demise of Willy, messing around and adding a pixel collision part (that did not kill) meant so much testing was done across the three modes. In Normal and trainer, Willy will not die. In expert he will. (So I missed out checking for certain conditions in expert mode) The above would also suggest falling into a switch will have the same problem. (on a bigger scale and more likely to flag collision) ------------------------------- Moving one line of code has removed this problem.... I hope the change in code order from Update willies position punch hole for willy move sprites draw sprites draw willy to Update willies position move sprites punch hole for willy draw sprites draw willy Where the switch is updated by the move sprite routine. --------------------------------------------------------------- Final game version accessible via This Link

And an addendum for the quirk. If you jump vertically and activate the switch, jumping across the activated switch does not kill. Oh the fun looking for the quirk in code.!!

Jumping vertically switches the switch, jumping at an angle kills willy... So a bug. Which I will have to duplicate myself in code to find out what is happening. Thanks for the feed back. I will investigate the problem. --------------------------------------------------------------- Final game version accessible via This Link

Looked at the code for Kongs demise. and he does give the score for each cycle of fall. SO I apologise for thinking he did not. As I have repeatedly stated, my code does not tend to duplicate other peoples code. I look at the problem and write my solution to that problem. I wonder why I thought the original gave a lump Bonus.

example of change. When Kong falls he increases the score for each frame of fall. The Bonus Given by Kong is dependent on permitting Kong to fall all the way. Touching Kong in expert mode curtails the fall of Kong, as Willy dies in that instance. This change means the full bonus of Kong's fall is only achieved when he has completed his fall. The older simplistic method gave the bonus in one go. Even if a few frames later Willy dies.

In trainer mode and normal mode touching a sprite saps air. Kong if visible is always active. In expert mode touching Kong will always kill Kong can not deplete air or kill Willy by any means other than contact. Kong is not interested in any graphic it passes over. Only Willy tests for collision. Only Willy can kill for collision. In Normal and training mode the only way to die is depletion of the air supply via Nasties/sprite collision/time/ and falling too far. Complete re-write of every bit of code. Kong kills in expert mode if touched. Saps air if touched in normal and training mode. (NOTE the air is NOT set for Normal mode - so no difference in air for later levels and therefore no difference "air wise" between normal and trainer) ------------------------- Not everything is fixed and written in stone. A light switch might be activated by pushing down. In most cases that is true. However an intermediate switch used in halls permits the switch to be in any state. Activated by pushing up or down. Having something different does not make it wrong, it is just different. Otherwise you would stand for a long time waiting for the light switch to be activated only by pressing downward. (apologies if you only use push button and the status of the button is not up or down) --------------------------------------------------------------- Final game version accessible via This Link

Every cavern has a room number. Printed along the bottom of the screen. Only the final cavern moves to stay the final cavern. Every uploaded version states when it was uploaded and what beta version it is, in the scrolling message. The number of caverns was expanded to 27, might expand it to 28.- probably have space for more - have not looked, I have never uploaded a version where standing on nasties is removed. I mentioned in a post that pressing "T" switches the mode. I will add the message probably somewhere on that screen. I do not want a string of versions giving a chronicle of what I am doing. So I will probably not upload anymore versions. The basic story was he returned to the site of his old explorations. With that in mind I edited the basic caverns. No reason they stay as they are now , and no reason they stay in the same order. The chronicle of updates is why any old versions are removed. Uploading a version that is obsolete serves little purpose. Later versions use slightly differing graphics on the portals for each mode. To give a visual indication whilst playing in a mode.(not uploaded) The switches have for one reason or another, have lost their activation. I have played and activated them numerous times.... So looking for the problem. The problem was the switching "off" of sprites for the rooms in various modes. In Trainer the last two sprites are removed. In Normal just the last sprite. And in expert none. The switches are activated by the Switch Guardians. (Kongs) . The switch guardian had been removed from the room, and therefore monitoring of the switches had been removed. In expert mode when the switch is active. Activating the switch is the only way to collect one of the objects .... Easy fix -I will change the order of the guardians. Done - reactivated- (not uploaded) The removal of guardians was just a rough and ready method. I will re-order them to adjust the spread of guardians across a room. At present it becomes obvious that in most cases the lower guardians have been removed in a room. Drifting pixels- I go bored with the static pause. Thanks for the feed back. Having a variable mode play game has not made this easy. Far easier to detect collision and just kill,. Far easier to have a fixed room and sprite layout. --------------------------------------------------------------- Final game version accessible via This Link

in the here and now I use the "MP" engine. At a later date I might use the "NS" engine - which I have not written yet in 128k .

1) "cessation". No spell checks in an assembler. So once it is written it stays as spelt. --- Duly changed from "ceasation" to "cessation". 2) The penultimate screen was I thought a fairly easy screen. Compared to some of the earlier ones. 3) The problems with adding diagonals is they traverse so much of the screen. That avoiding them is far more difficult. In JSW2 and JSW128Vk/vl/vm the diagonals mainly follow stairs. It is possible to follow them up or down a stair and jump over them. When the game has no stairs and the diagonal traverses horizontal platforms. The sphere of influence from a diagonal is far greater. Which is why they are used so sparingly. 4) No plans on adding an in game click routine. Keyscan routines. From a brief read of the "NEXT" specifications. I would not imagine the Next changes the key scan in any way. If you finished the game in "TRAINER" mode, then all that happened was. The title screen came up, stopping continuation. This is not what happens in "NORMAL" or "EXPERT".. I note your dislike of those scrolling messages. - I will write a routine to display the text in fixed normal size and see what that looks like. (for curiosity reasons) No decisions will be made until I see what it looks like. Addendum Yuck. is my description of normal sized text on the screen. --------------------------------------------------------------- Final game version accessible via This Link

Now, how about a short swing being implemented in MP? Terminology that I am not familiar with. Best guess being a rope. - A rope is unlikely to appear due to the nature of collision detection. In JSW the sprites check for collision, (as it does in Manic Miner). In Manic Panic the whole logic of collision detection is inverted. The sprites no longer set and check collision, that job is solely done by Willy himself. A rope would need a very special case setting and .... I see no immediate way of doing it. Awesome! Will never complete it it's far too hard, but even so JSW128VM has a portal mode. In the portal mode, you do not have lives. You only have a time limit. You can play a screen/multiple screens as many times as you want. Each Death is treated s a reincarnation back to the last portal. The portals act as a save game state. (e.g. the game has an inbuilt save state facility)

The jump on bush part has been removed. (post #50) In older versions the ability to jump on nasty1 or nasty2 was permitted. and the ability to seemingly jump of the top of the screen resulted. The sprite disappears for a brief moment. The address is calculated and placed on the ROM , so consequent drawing of the sprite is done on the rom. The restore of the sprite is also done on the rom. The attributes calculated to colour willy in are drawn incorrectly I assume on the Master Attribute screen. It was something I would have eventually changed. It had been noted and did not crash the system. I am taking a slow approach to doing the code. I am in no hurry to do this. If the opportunity arises for other activities, then this will be dropped and those other activities pursued. Addendum I checked the actual code. The attributes check where the screen is. So I already stop draws off the screen. Both the attribute for colouring and the pixels for drawing. --------------------------------------------------------------- Final game version accessible via This Link

Standing on Nasties:- The original file allowed nasties to sap air. This was not the original plan. In the original game file all contact killed Willy as is the normal action. Since this was a BETA file I included the action of air sapping purely because it allowed the screens to be traversed easily without instant death. The one person feedback I received prompted me to expand the air allowance and still permit contact with nasties/sprites and falls to continue as if nothing much had happened and the super generous air supply made movement around easy.( far too easy) The allowance of standing on a nasty was not a problem originally, when the game did not allow such generous air supplies or death on contact with them. However with the massive amounts of air that is available now, The ability to climb on nasties or stand on nasties needed to be curtailed. I have spent half an hour changing the logic surrounding all the nasties. The change makes nasties un available to stand on. --------------------------------------------------------------- Final game version accessible via This Link

Then it has fulfilled its design brief. From the start the screens have increased in size. The screen after the old central cavern screen, is designed to be a visual shock. --------------------------------------------------------------- Final game version accessible via This Link