Norman Sword

Cavern 3 :- of note is the little jiggle Willy does at the right end of the top platform to fall to the platform below. I had several tries at adjusting that wiggle and whilst it might look neater, it losses a frame. Is anyone interested in me writing a version where the game can play any room to completion using the data provided above. E.g. a game version that plays normally or allows auto completion of any room. Undecided how that would look or perform. Using the name Crem - provisional name for game would be Creme de la Creme

It would be interesting to see the data for all the rooms published in such a format.

Scripted Movement. I altered the keyboard input routine to accept input from a data stream. The data stream is simply a file that I write, with values for the various inputs ( left, right, jump) The room is played and the data is taken from the data stream one item at a time, which simulates the keyboard input. I simply play the room and watch what happens, and add or delete the data to make the jumps at the exact timing I want. After I have perfected a particular jump or movement. I start adding more data to simulate movement to the next point of interest. The data streams are simply optimised movement data from myself. I played (typed data) for the first two rooms, just to establish what my optimised play would do. This method is Not going to find the best route. It will play a route that is picked and adjust the jumps and walks to one frame accuracy. Part of one data file (generated by visual play - type data and watch what happens) DB 0,0, 0,0,0, 0,0,0,0,0,0,0, 0,0,0,0,0 db 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 db 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1;,1,1;,1,1,1,1,1,1 ;START FALL DB 0,0,0 DB 1,1,1,1,1,1,1 ;WALK DB 5 db 0,0, 0,0,0, 0,0,0,0,0,0,0, 0,0,0,0,0 ;jump collect db 0,0,0,0,0,0,0,0,0,0,0,0,0,0 ;floor collapse db 2 db 6 ;jump out of hole db 0,0, 0,0,0, 0,0,0,0,0,0,0 DB 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ;WALK TO FALL DB 0,0,0,0,0,0,0,0,0

The first two cavern played by scripted movement. one cavern per script Score 1724 (cavern 1) and 1975 (cavern 2) Not carrying on- interesting one night exercise. -------------------- Watching cavern 7's erratic generated movement. I decided to do my own. The route taken by my script is a bit more relaxed. Still gets the same score. This has shown me not to do any more, it just is not what I want to do with my time. sc1_1724.tap sc2_1975.tap sc7_1824.tap

I have wandered around several of the screens. Mainly just wandering around the lifts and watching the map show where I was. Interesting the part where you search items. (for no apparent reason). Played around with the editor. Took a bit to work out the some of the mechanics. Any plans on allowing save states (I did not notice that facility, but they could be there). From the glance I had it seems promising. If Brave had managed to open and play the game, I hope your version plays a bit faster than the version I tried (it makes FireFox look fast)

I had read some of the posts regarding this topic. It was not something I needed to know, so it did not concern me. I looked at the code only a few minutes before my only post on this subject.

speed in browser on my pc. walking along the top from right to left the full width of the first room Chrome 8 sec Opera 8 sec Opera GX 8 sec CC browser 8 sec Microsoft Edge 8 sec Firefox 28 sec Brave 47 sec

layout in groups of 3 value bits key1 key2 key3 1e 11110 q p a 1d 11101 w o s 1b 11011 e i d 17 10111 r u f 0f 01111 t y g 1f 1f 1d. s key3 1f 17. 1f u key2 1f 1e. 1f p key2 1b. 1f 1f e key1 17. 1f 1f r key1 1f 17. 1f u key2 1f 1f 1d. s key3 1b. 1f 1f e key1 17. 1f 1f r key1 laid out in a different way - - 1d. s - 17. - u - 1e. - p 1b. - - e 17. - - r - 17. - u - - 1d. s 1b. - - e 17. - - r Hope the above helps

The usage of random implies a random number. The numbers generated are sequences of numbers, predictable and fixed in sequence. The are two forms of boot. Which falls is unknown by me. The sequence is determined by the sequencer. So it can be in any order. When I was changing the graphics I was repeatedly aborting the game and trying to see what the graphics looked like. At one stage I was getting convinced that the new graphic would never be seen, as I watched the old boot fall time after time after time. The suddenly it changed graphic to the high heeled boot.

Manic Panic uses a sequencer for generating sequences of numbers. The Amazing Final inspection is a result of that sequencer. Since the graphics have no bearing on how the room is played, I allow the sequencer to generate new displays. For those who posses the version of Manic Panic with a cheat mode, it is possible to stop the sequencer from drawing new designs by simply moving backwards from later rooms into "Amazing Final Inspection" The reason moving back through the rooms stops the sequencer in its tracks, is because the sequencer is reset for every room played that needs a sequence of numbers. The rooms using the sequencer will play exactly the same on every replay with no variation. The room water permeation uses the sequencer in a trivial manner. Each time a drip hits the bottom a note is generated. The note is taken from the sequencer. (note this variance in pitch has no impact on game play) In the room Particle Collision Chamber the worm kicks the balls upward. The SFX for the kick is made from two parts an initial noise taken from the sequencer data and a fixed end part. ( note again the variance in sound has no impact on game play) The height the worm kicks the ball is also generated by the sequencer, and due to this variable making a difference in how the room would be played the sequencer is reset every time this room is entered. So that the room playing sequence is the same every time the room is played. The seemingly random dripping of the drips in Water Permeation is calculated by FIXED data changes. It never changes from one game to the next. The drips generate a very steady sequence of time shifts, (nothing to do with the sequencer) Since the Title screen is NOT a game playing screen, the kick the worm generates and all the changes in movement are taken from the sequencer. So they will and do change. The graphic used to squash Willy is also taken from the sequencer, the sequence is not easy to determine due to the length of the sequencer data. It could display the normal boot 20 times in a row, such is the data generated by the sequencer.

No one seems to notice or did not bother commenting but the room "Amazing Final Inspection" does keep on drawing new Mazes on each appearance.

I am very grateful that you took the the time to play through to completion (more than once) The final cavern "Control ONE" does display the room name for 128 game cycles unless an item is collected. Since an item is next to the start position, it can be collected very soon after entering the room. From your video the room name is seen for every final room, then the item is collected and it reverts to the status line. The crushing boot onto the plinth does not follow any fixed pattern. It could just as easily have never changed for the duration of all your plays. The speed is deliberate - hence "Manic Panic" - The control of Willy is exactly the same as Manic Miner. No change in method of key detection apart from using only the "A" register for all reads. Room/cavern name are just Tags added to a room/cavern. If I rename reapers Harvest to Reapears Harvest. it still fulfils it design criteria of giving the room/cavern a TAG. Not something I plan to change. So no plans on any form of update, due to not seeing any problems that need changing.

The scope of the patch/change is such that it is possible to stop individual sprites from moving. Just add the room number and indicate which sprite needs to be left alone. This enlargement of scope can/could stop individual ropes from being moved in certain rooms. The chandeliers are phase moved in only 2 cycles. so Not much scope for it looking different. I did contemplate altering the vertical limits in a similar way to the horizontal limits, but whilst it is easy to do. It starts to introduce more variables for problems to occur. I am aware of potentially one or two ways for the routine to freeze. So the introduction of vertical limit checking was a step too far. (having said the above, it is probably not a problem with the game data as it is) So another patch to add the the list of JSW patches. Next week I am aiming for the woodcraft patch

The technical changes from the original file I listed. It was noticed that out of all the playable rooms. Only 6 needed data to change how the routine modified the room. So this file stores only six room numbers and the data for those 6 rooms ( and an extra one for luck- CPIR) The original query wanted a period of immunity after death. Whilst easy enough to do. It needs more code than I was prepared to write. The code is not the problem. The backward reference to the original is. After playing the modified rooms I noticed I was occasionally killed as I entered a room. The random aspect meant that I would re-enter the room and again in most cases the sprite would have been moved by the routine, and would start in another place. So respawning back in the same place was not a fatal flaw. After wandering around heaps of rooms, it became noticeable that this occasional problem was mainly the horizontal sprites. (it might happen with vertical sprites - but not on my wandering) So instead of addressing the immunity problem I instead addressed the problem of sprites being in the vicinity of room edges instead. The added code that is not in the original listing, takes the trouble of moving any sprite that is left near a room edge. This added code will move sprites away from the immediate vicinity of the left and right edge. It only moves horizontal sprites. From the wanderings I had, this small change allows in most cases the entry into a room without a problem.

Multitude of ways. I only looked at the data. And whilst looking at the data I added an extra entry. A multitude of options to correct the CPIR step dec hl change the offset to only five instead of six or just add an extra byte to the data. In every case the file grows by one byte.

The problem arose for a far more mundane reason. CPIR. I set up a search for the room number then once it was found stepped over the room numbers into the room data. So searching six items and stepping over six items to the corresponding room data. Simply forgot that the CPIR stepped past the data it matched. I just added an extra byte of data to allow for the CPIR step after a match.

A quick look at the code and I have spotted the problem. One byte short in data - I will update the file above. The code assumes that this is the original JSW and only stores the rooms that need the sprites adjusting (6 rooms). All the other rooms are assumed to be full adjustment. The code steps through the room numbers and then steps into the data. However in the original file. The step onto the room data that specifies which sprites should be moved in those 6 special rooms was stepping one byte short. So it found the room was special, but did not match the special room with the correct data for that room.

The colours are from an lcd widescreen monitor. Nothing special.~ Provided here is the final version of the random patch. This is similar to the listing I provided, but is extended in scope. Using an original JSW file - which I am not providing. ; Load JSW - ORIGINAL - RETURN TO BASIC ; load this file over JSW - a 238 byte file - code loads at 65400 ; RANDOMIZE USR 65400 - TO INSTALL PATCH ; RANDOMIZE USR 33792 - TO PLAY Not extensively tested - main purpose is to see what the game runs like when modified in such a way. This file is one byte bigger. Which shifts the room data by one byte and corrects the problem (I hope) rand_sp.tap

DSCF9962.MOV The centipede moving with a smoother path.

Yes a 256 loop when b=0 with DJNZ. The edits I do when I change the code from the original (as written in my own version) to the version that is seen above. Create more problems as I go along. I constantly change the code from the original layout, without any checking/testing. Sometimes those modification create all the subsequent edits I need to do. I think it is 99% there.

supposed to say #80e0- When I write these routines I do not have the original data. I have my own and I do not use direct memory references, I have to work backward and calculate where the original might have been. Yes it should be INC A. I will slowly correct whatever I see as being incorrect. It does however work as seen. The problems arise most of the time from having to change most of the code to fit in with the original data/layout. So I will do another edit/update and change the { inc b } to { inc a }

This has been tested and works exactly as specified. It needs the room data changing to stop the giant heads being shifted and the forgotten Abbey and the attic data being shifted- An easy enough task Half an hour to write. Somewhere near the end of the room set up a call is made to rephase_room The data at offset #e0 in every room is changed to #00 modify the sprites or #ff leave alone. Or the bits in the byte signal which sprites must be left alone. So writing 1110 0000b would instruct the routine to leave the first three sprites alone. ( eg. stop it phase shifting the big heads if they are the first 3 sprites in a room) random_sp equ #80e0 return_2_me equ #91b6 entity1 equ #8100 ; rephase a room rephase_room: ld hl,random_sp ; this address is any free byte in the room data - each room needs this setting up - most rooms can be left as zero ld a,(hl) cp #ff ret z ld c,a ; this is the entity bit move mask ;initialise the guardians ld a,#c9 ld (return_2_me),a ; modify the next sprite entry - return2 me is at address #91b6 LD IX,entity1 ; Point IX at the first byte of the first entity buffer at L8100 Phase_shift: ;test the end of sprite data then test the bit held in c; this signals a possible move LD A,(Ix+0) inc a ; cp #ff jr z,no_more bit 7,c jr nz,a_static cALL RANDOM AND 127 INC A ; instead of INC B LD B,A SHIFT_IT PUSH BC CALL L90C4 ; MOVE THE SPRITE POP BC DJNZ SHIFT_IT a_static ld de,8 add ix,de rlc c jr Phase_shift ; ensure it is put back no_more ld a,#11 ;ld de,# ld (return_2_me),a ret ; the RANDOM routine does not produce RANDOM numbers it produces a sequence of numbers that is fixed in sequence. The number of digits in the sequence is large before it repeats. At machine speed calling random will produce a pattern based on its output. RANDOM: PUSH HL S_M_C_address equ $+1 LD HL,$-$ S_M_C_SEED equ $+1 LD A,$-$ xor (HL) XOR L XOR H inc hl res 5,h LD (S_M_C_address),HL LD (S_M_C_SEED),A POP HL RET ; *** NOTE *** only 6 rooms have a value that is not 0 (zero) - 7,20,28,39,42,48 ---- rooms value start at 1 in this list ; values for byte #e0 ;"The Off Licence" 1 db #00 ;"The Bridge" 2 db #00 ;"Under the MegaTree" 3 db #00 ;"At the Foot of the MegaTree" 4 db #00 ;"The Drive" 5 db #00 ;"The Security Guard" 6 db #00 ;"Entrance to Hades" 7 db 11100000b ;<<<<<<<<<<<<<< ;"Cuckoo's Nest" 8 db #00 ;"Inside the MegaTrunk" 9 db #00 ;"On a Branch Over the Drive" 10 db #00 ;"The Front Door" 11 db #00 ;"The Hall" 12 db #00 ;"Tree Top" 13 db #00 ;"Out on a limb" 14 db #00 ;"Rescue Esmerelda" 15 db #00 ;"I'm sure I've seen this before.." 16 db #00 ;"We must perform a Quirkafleeg" 17 db #00 ;"Up on the Battlements" 18 db #00 ;"On the Roof" 19 db #00 ;"The Forgotten Abbey" 20 db #ff ;<<<<<<<<<<<<<<< ;"Ballroom East" 21 db #00 ;"Ballroom West" 22 db #00 "To the Kitchens Main Stairway" 23 db #00 ;"The Kitchen" 24 db #00 ;"West of Kitchen" 25 db #00 ;"Cold Store" 26 db #00 ;"East Wall Base" 27 db #00 ;"The Chapel" 28 db 11100000b ;<<<<<<<<<<<<<<< ;"First Landing" 29 db #00 ;"The Nightmare Room" 30 db #00 ;"The Banyan Tree" 31 db #00 ;"Swimming Pool" 32 db #00 ;"Halfway up the East Wall" 33 db #00 ;"The Bathroom" 34 db #00 ;"Top Landing" 35 db #00 ;"Master Bedroom" 36 db #00 ;"A bit of tree" 37 db #00 ;"Orangery" 38 db #00 ;"Priests' Hole" 39 db 11100000b ;<<<<<<<<<<<<<<< ;"Emergency Generator" 40 db #00 db Jones will never believe this" 41 db #00 ;"The Attic" 42 db #ff ;<<<<<<<<<<<<<<< ;"Under the Roof" 43 db #00 ;"Conservatory Roof" 44 db #00 ;"On top of the house" 45 db #00 ;"Under the Drive" 46 db #00 ;"Tree Root" 47 db #00 ;"[" 48 db #FF ; no sprite data ;<<<<<<<<<<<<<<< ;"Nomen Luni" 49 db #00 ;"The Wine Cellar" 50 db #00 ;"Watch Tower" 51 db #00 ;"Tool Shed" 52 db #00 "Back Stairway" 53 db #00 ;"Back Door" 54 db #00 ;"West Wing" 55 db #00 ;"West Bedroom" 56 db #00 ;"West Wing Roof" 57 db #00 ;"Above the west Bedroom" 58 db #00 ;"The Beach" 59 db #00 ;"The Yacht" 60 db #00 ;"The Bow" 61 db #00 The data followed by ;<<<<<<<<<<< is indicating values that are NOT zero

In jsw there are less than 128 entities. The entities are jiggled around and form all the sprites in JSW. When an entity is defined it defines certain parameters. The parameters it defines for a sprite that moves vertically is the upper and lower points and its vertical start position. The entity can then be moved horizontally to its start position. The centipede in the attic has an entity defined for each and every part of the centipede because it can not move the vertical start position. The routine I wrote uses the move start position (as written above) to move the fixed start position of one entity to duplicate the original multiple entities defined. So yes the statement I made was correct. I will check ---- If the above is correct.

Further elaboration on starting in a random place. When the room has been drawn and all the room data has been drawn. In jsw128VM, VK and VL a routine is called that moves the start position of designated sprites. For a working example. I will describe the sprites in the attic. In jsw128Vm they are all the same sprite. The program only stores one sprite and not the sprites that the standard JSW stores, which is one sprite entity per part of the body. For each part of the body the horizontal position is changed (as normal for a sprite) The vertical part of each sprite position is fixed. The program calls the movement routine a specific number of times for each part of the body. This repeated calling allows the start position of each part of the body to be moved a set distance from the original start position. The sprites are finally drawn when the room is drawn with all the parts having been moved from the single entities start position. This might sound like it will be slow to execute. Yet I have never witnessed a delay jumping from room to room in JSW128vm and no one has even hinted that a problem occurs in the time taken to move from room to room. These type of convoluted and extended routines are not part of the main game playing loop, The amount of processing that can be undertaken when jumping from room to room is massive. In JSW128VM the amount of room generation code is massive, but as stated it is not a problem.

Easy to randomise the sprite start positions within their paths. JSW128VM runs a similar set up. (just not obvious it does so) The major problem beside IDS and sprites starting in the entry position of a room. (which causes one death) is the paths of sprites that do overlap with each other. The monks in the forgotten Abbey will collide with each other.--- (are there other rooms?) What you have suggested is to me, very easy to do. Even adding a period of immunity is very easy to do (for me). Having said the above I have no plans to write such a game. Starting in a random place - ignoring the other aspects of the game. When the room has been generated and it normally returns to the main part of the game. Instead for each sprite call the movement routine for that sprite a random number of times.