Norman Sword

Tools used for writing Manic Panic Context (text editor for writing the assembler code) Pasmo (A z80 assembler) Fuse (for testing assembled code) QBasic for tedious calculations. Code was written as needed - no usage of libraries. No usage of other programs - apart from those listed above. All additional graphics were typed in binary. Music data and music code directly typed in. Room layout data (platform positions)- typed in directly in hex. Sprite movement and room specific data - typed out by hand. Sprite movement - mentally calculated and typed in. Room graphic tile data (numeric data was visually taken from another program I wrote MANIC 40 MINER and then typed in. I allowed macro's to transpose the data. The main code block is 9,155 lines of comments, equates and code. which is 450k in size The sprite file is 1,480 lines of hex statements and binary statements. which is 41k in size The room data is 3,450 lines of macro's and data statements. which is 128k in size Every time I changed the program logic and needed different data - I edited the above files with a text editor.

Willy having a directional beam of light. A topic I have known about for many many years. Which was not a new idea for me, so- Sorry to disappoint you, but the original code and idea was mooted for Jet Set Willy 2. The room with the trip switch was designed to switch off the lights and implement a circle of light. The circle of light code was written, but took too long to implement as a game feature. I'll expand on that - Derrick P Rowson had written a graphic routine to illuminate a circle of light. If the code had been implemented on the spectrum first the circle of light would have been implemented. Alas the original version was on a CPC 464 and the speed of processing was not fast enough.

View File Manic Panic Manic Panic. Plays on ZX Spectrum and similar hardware. Runs and plays in48K This game could have been written when the originals of Manic Miner, Jet Set Willy and Jet set Willy 2 was written. It does not need the memory or hardware of the expanded versions of the ZX spectrum. very very brief note:- The original plan was to create a full sized playing screen game. An upgrade on the 2/3 screen playing area of MM and JSW. I decided to continue the story of Miner Willy. Willy Started out exploring in Manic Miner, and hit the jackpot. He then splashed out his monies on a new mansion which was explored in Jet set Willy 1/2 and 2+. In the present day his memory of the past is playing tricks on his mind. Did he switch any of the robots off in Manic Miner? In Manic Panic I leave you to find out. What he does next Whilst the basic code was easy enough to write, I did encounter problems with breakup on one part of the screen. This problem nearly caused me to to cease writing and scrap the idea. I persevered and after two weeks I had most of the basic code. The game has multiple playing modes 0) Trainer, 1) Normal, 2) Expert, 3) Ace , 4) Lantern, 5) Torch. Each mode differs from the others modes in a specific way. Outline, based on how I remember the code. Modes 0) Trainer -- Full oxygen ---- Slow oxygen depletion ------ Oxygen depletes on contact - (-2) sprites - No final Bonus - No end game 1) Normal --- Metered oxygen - Normal oxygen depletion ---- Oxygen depletes on contact - (-1) sprite -- Final Bonus ---- End game ----- enables ace mode 2) Expert --- Metered oxygen - Faster oxygen depletion ---- No contact allowed (death) - all sprites -- Final Bonus ---- End game ----- enables ace mode 3) Ace ------ Metered oxygen - Very fast oxygen depletion - No contact allowed (death) - all sprites -- Final Bonus ---- End game ----- playable only if another mode was completed. Extended modes - added as a novelty 4) Lantern -- Metered oxygen - Normal oxygen depletion ---- Oxygen depletes on contact - (-1) sprite -- Final Bonus ---- End game ----- enables ace mode 5) Torch ---- Metered oxygen - Faster oxygen depletion ---- No contact allowed (death) - all sprites -- Final Bonus ---- End game ----- enables ace mode -- oxygen depletion stops if static. The extended modes adds a lot of code. And are based on the idea that the caverns are dark and are illuminated by Willy in two ways. In lantern mode the cavern is completely Blued out. Willy can use the light that is attached to his helmet and illuminate the cavern. The light will point in the direction of Willies travels. If Willy is walking Right the the beam of light from Willies helmet will also shine to the right. Conversely for the left. When Willy is static and is not moving horizontally Willy can rotate the beam of light in either direction. The keys for rotating the beam of light are the keys "H","J","K","L" - with "H" and "K" rotating in one direction and "J","L" rotating in the other direction. The rotation keys have inbuilt delays (similar to keyboard delays). The items are set to still colour cycle or animate in the blued out room , so their positions are always visible. The portal is also still visible. The above (lantern) was extended into another version. The Torch version. Here the room is blacked out, which makes the surrounding platforms disappear. In order to facilitate playing in such a room, and not make it pure guesswork or committed to memory in order to play. A small area around willy is Blued out, this area shows the platform willy is standing on. The steady depletion of oxygen is stopped, whenever Willy is static (stopped) and the rotation of the torch beam can be undertaken to illuminate other parts of the screen. To further facilitate travelling around the screen, all items/objects/keys collected will briefly flash and illuminate the room when they are collected. I have played every cavern in Lantern and in torch mode, whilst it can add a layer of difficulty to each cavern. The fact I have completed them shows me they can be completed. The screens have not been memorised by me and since they are all relatively new, I play them with only a limited memory of how to play them each time I see them. Changes from MM/JSW This list just touches on some aspects of code change. I rewrote everything- some with better design than others. Full screen playing area - an increase of nearly 50% Willy now has a sprite mask. All sprites can move in any direction. Room events are changed to sprite events. E.g. Kong is a sprite and not a cavern that has Kong in it. Sprite events can be mixed. e.g. Kong- Skylab - light beams etc can all exist in any cavern. Sprite events specify their own graphics. e.g. you can have differing graphics on the Skylab graphic event in the same room. Sprites can cross other sprites - without killing Willy. Sprites can cross graphics in the background without killing Willy. every sprite can define its own graphic. Sprites can be 16, 8 or 4 pixels high. Addition of worm collision sprites. Addition of time phased dropping sprites. Addition of animated items/keys. Colour cycling on items/keys cycles correctly in 7 cycles and does not repeat in cycles of eight with duplicate colours. Keys/items can animate in 1 phase, 2 phase, 4 phases. Cavern graphics allow up to 16 differing graphics per room. Cavern graphics incorporate a new style of tile - being an invisible/ignore tile. Graphics such as the nasty graphics are during game cycle allowed to act as nasties and also be ignored. -- reason for ignore tiles -- In JSW/MM - Willy can stand on any tile -- These tiles need to be ignored due to being able to survive nasty contact. Graphics do not suffer the duplication of colours bug that plague the differing versions of JSW and MM. Possible to have two differing tiles and one colour. Multiple on screen Conveyors can be animated in different places. Conveyors can have both left and right conveyors in the same cavern. Special code added to allow Willy to straddle two conveyors and not lock the movement keys out. Air bar is depleted in a progressive manor. Depletion when full is slow. When nearly empty depletion is fast. Rate of depletion is based on the height of the oxygen. The change in speed of depletion is constantly changing. Air bar depletion is also changed by the game level played. Easy levels use a slower rate of depletion compared to the harder levels of play. Dual title music playing routine Music routine play pitch corrected notes. Music routine illuminates correct keyboard keys. Music routine allows music tempo change. Music routine allows notes of differing length Music routine allows rests. Music routine can play notes from 5 octaves Multiple game playing modes 0) Trainer, 1) Normal, 2) Expert, 3) Ace , 4) Lantern, 5) Torch. Each mode differs from the others modes in a specific way. Behind the scenes a lot of added code is taking care of several aspects of space management. Since this is just a short note those aspects and the details of the changes will not be added here. Submitter Norman Sword Submitted 12/09/2020 Category Manic Miner [Remakes]  

My break from posting was extended. In the end quite a bit bigger than the 30 days I visualised. Welcome back. I will shortly post the version of Manic Panic that was created during that break. That was version 1.4 - which quickly became V1.5 due to typographical errors. (it's a tradition I missed out a letter "i" in one word)

Tonight I stop all posts and take a rest from my computer for a month. So today is the 21st july 2020 , I will take a break from z80, zx spectrum and forums until 21st August 2020. The slow drip drip of additions stops. Have a nice summer.

Thanks I will edit the name..... Which incidentally was copied from post #187 The height of the beam as opposed to the width, is not fixed. Depending on the depth needed to see down further I could extend the range downwards.

Pgyuri Pgyuri's Halo:- which is a halo of light surrounding Willy. Normans Sword's Light beam :- Is a light beam which is rotatable and directional Rotation of beam Pgyuri NO Stopping of clock Pgyuri NO Display of objects Pgyuri NO ; No feedback to where the objects are. No feedback for object collection Display of portal Pgyuri NO ; No feedback when the objects have all been collected. No feedback where the portal is Playable on unknown screen Pgyuri NO : the halo will not project across gaps. Jumps to other platforms are just guess work. Halo of light Pgyuri yes Directional beam Pgyuri directional bias on halo Ability to see ahead Pgyuri NO Ability to see above Pgyuri NO. Object just two blocks away can not be seen. Jumping to collect an unseen object is guess work. Hazards can also not be seen. Ability to see below Pgyuri NO objects just two blocks below his feet can not be seen. Falling of a platform to a lower platform is Guess work From this point onwards I will always refer to the original routine as Pgyuri's Halo. And mine as Norman Sword's Light beam.

in jest- the walls in the cavern are made from translucent crystals. Such as diamonds, emeralds, jade, etc. the light would pass through the crystals and illuminate the scene behind. This is the reason for Willies riches.

Not something I will look into. Black on blue turned into blue on black. The alternative being - Black on black. No matter what is checked there is no alternative where the paper is black. I set out to do a quick interpretation of the original code and extend it.. That code took around two days to do. The added code checking I have done since was to increase its play ability. Something I regret doing, it was a path that I added onto the code, that I still have misgivings about. The quirks will come thick and fast. I already know of several others. Cast you mind back to JSW and MM in their original guise and count the dozens of quirks they exhibit. How many years have you personally spent trying to correct them? The code I have written will exhibit lots of strange traits. Most of which I will not even attempt to change.

Played a few screens, with the particular interest in what the conveyors do in candle mode I encountered the static conveyor problem, which is not the same as mentioned elsewhere. (but similar to) In cavern/room 3 there are two low conveyors. The first one that can be jumped on is the conveyor on the lower right. If I press and hold the right movement key and jump onto the conveyor. The wall on the far right will stop my progress. The conveyor is trying to move me left. Here we have a static condition. But the oxygen will still deplete and we can not rotate the beam. I changed the basic code and changed what was being examined for static conditions to be met. Simple enough change, which also needed the drawing of Willy to also be very slightly changed. Just a re-order of the code which calculates the sprite definition to be drawn. The changes in code seemed to do the trick. The next problem was how the static condition was handled by the oxygen/timer. The new problem was caused by the sequence of updates in the code. The timer needed to be updated after Willy had moved, instead of before as was originally coded. Again a simple enough change. With the above changes. The actions of Willy on a conveyor are handled differently. -------------------------------------------- Jumping in cavern/room 3 onto the right lower conveyor and keeping the right keys pressed. When willy hits the wall and his animation stops. With the above change. --- The clock stops and Willy can rotate the beam. Does this merit another update ? - A version mp_V13.tap is added to mp_V12.tap accessible via This Link ------------------------------------------ I probably need to start some other code - and not play this game more or even read the source code. Most of the update I have done recently, stem from just editing the code layout to make it look neater. This entails doing global name changes, making all tabs and all comments line up exactly in the same column. etc Something that does not happen when the code is being written. However this does often alert me to things I can do with already written code. I might be re-reading a piece of code written a few week ago. looking at it afresh will sometimes trigger a response in me, of how I could re-write a sequence to be faster or smaller. This re-reading code, can end up as large re-writes of code. ------------------------------------------------- Addendum to the comment above... The lining up of comments, tabs code etc, is actually done by another program I wrote. Its purpose being just to standardise the look of the code. It takes my source code and re-formats into the look I want.

The worm that plays - The ball playing worm on the Title screen. After I wrote the routine, I was very tempted to add a screen with just the worm on the bottom of the screen and the balls being fired up across the screen. It would have been similar to the Sky-labs, only with the objects moving up and down from below. If I do any other games - I might add the worm.

Updated the title screen animation. Removed all other versions. 1 version which has all the updates in. That's my lot on this format-version. This Link

Removing most of the checks and leaving just two checks. On the same condition. 1) if a change in movement status. Then direct beam. this detects change of face direction. when static. 2) If moving left or right then direct beam. ------------------------------------------------------- In the spiral room. Beam can be rotated downwards as willy falls. Beam can be rotated upwards as willy climbs In the Eyeball room beam can be rotated as the floors collapse, or as you climb vertically In Eugenes . A quick walk of the first platform, and on the long fall. the beam can be rotated as you fall. A simple animation change from facing left to facing right. The beam will swap sides. No checking for jumping/falling. Just the movement status now (if moving) or a change in status ------------------------------------------------------ Airborne status is set to 6 when starting a fall. This is the point at which which forward movement is stopped and willy falls vertically. No longer testing for this condition. The code I used, lasted only 10 minutes, before removal.

Without looking at code. The conveyor problem could probably be implemented by looking at the keycode values. I.e. the routine for movement generates a composite value for keypresses. A conveyor effectively presses a key. If the opposite key is pressed then we have a null situation. The movement action treats a null situation as a continuation of previous movement. If I read the keycode value and not the movement value of willy. Then it would be possible to treat a conveyor movement as a static movement. Something I will not do - I stopped at version 4.

Return of Kong Tried the above kong fall. The beam stays pointing sideways on the fall. - I will look at again later - after I have watched a film. Intermission on film:- I suspect a similar reason to the fact that the mechanics do not permit Willy to change face direction on fall. no matter how far he falls. Think Jet Set willy and the leap from the top of the building. Getting complicated to insert code to check if falling and at max fall value. Then permit beam rotate.....Airborne=6 when on a long descent I added a check for Airborne =6, (which happens on max fall) and permitted beam rotate. Need super fast reflexes to point the beam on fall. If I was to do these checks then it would make more sense to do a force of the beam to point downwards whenever willy is on maximum fall speed. i.e. when Airborne=6. the beam points downward.... I will set up a series of screen/border flags to indicate game wise when Airborne =6. To clarify to myself if this only happens on max fall. and if so. Force the beam to point downward. If too convoluted - I wont bother. Without even adding any code - I can already see problems. ----------------------------------------- Whilst it works checking for the fall value of 6, which forces willy to look down works.. It negates the ability to look upward. Jumping on the spot will keep on re setting the beam to look downward on every landing. To counter that you need to set automatic upward facing beams. And whilst at it, carry on and angle the beam depending on the arc of travel...... Whilst I probably could do all of the above...I wont. This was supposed to be a quick addendum, which supposedly stopped at version 4. ---------------------------------------- --------------------------------------------------------------- Final game version accessible via This Link

Therefore it is not the jumping that is causing the problem. (can remove that new check) but the static direction change. - 1 min and I can see what that does. Removed the jumping check By only checking for changes in Willies movement status. The instance of landing and turning around will switch the beam static turn around will switch the beam. Jumping directly upward will not switch the beam. jumping sideways which has movement will switch the beam. --------------------------------------------------------------- Final game version accessible via This Link

Easy enough for me to change---- would not be an instant change, only because of the number of steps needed to create a working version. As opposed to an assembly download. I will force the direction when jumping. Which is not done now. Changed. Still allows willy to turn on the spot without changing the direction of the beam. But the instance of jumping will change the beam direction immediately Changed again. Any change in willies status will change the beam to face, whichever direction he faces. so on the spot static movement, but a change in direction will automatically rotate the beam to follow the new direction. --------------------------------------------------------------- Final game version accessible via This Link

The beam follows movement. Not direction. I can see how that would be interpreted as a glitch. If static then the direction is whatever you want it to be.

Those coloured backgrounds in the cold room prompted me to re write the flashing objects routine for those rooms. behind the scenes the game runs as normal. Just before the screen is copied I apply the light beam effect. I felt it needed the objects and the portal permanently left on display. So the portal and the object routine are called Yet again mid way through the routine to insert the objects and the portal. Both routines take very little time compared to the major copying overheads. The coloured backgrounds do not look correct when the area around the object is not illuminated. So the original routines method of colouring an object onto the background, also did not look correct. So I had to add another routine just to animate and colour in the objects. The bonus was the routine did not need to draw the objects and was therefore faster. ------------------------------------------------------------------------ --------------------------------------------------------------- Final game version accessible via This Link

The candle mode(black background), was originally unplayable (as a game) due to not being able to know what was directly under Willies feet. The names, lantern /candle, are as names, strictly speaking wrong. In both cases Willy is using a directional beam lamp. Which from my experience of using torches . Spread a great deal of light in the direction they shine. And unless reflected back, leave your immediate surroundings pitch black. Originally in the black background mode, I directed the beam as can be seen, with a narrow beam starting out around the placement of the lamp on Willies hat. This unfortunately does not illuminate the area around Willies feet. The addition of adding reflected light to that beam was not a simple option (Not thought about in detail, until I wrote this explanation here) But the idea was not a simple and immediately viable option (more though and longer planning and it might have been) The none reflection of the light meant that where platforms ended was often just a guess. Remembering how far away that next jump needed to be, when willy and the platform was not visible, nagged at me. I could have expanded the light pattern to include Willy and the platform. The problem with that was it was NOT how a directional lamp works. A lantern or a candle give a localised light, which fits more with the description I have given to these levels. A localised light which would illuminate Willy and also illuminate the area around Willies feet. But Willy has a miners helmet, and on that is a directional lamp. The directional beam is as I have included in the design. The simplest method I could visualise was to just blue willy and the cells he was stood on. A very crude localised reflected light. Leaving the helmet light beam as originally coded, which was directional. When I tried out this simple change it at last allowed me to play several of the opening screens without a a great deal of trouble. To me the blacked out option was at last playable. Which is why the lantern / candle modes are now included. --------------------------------------------------------------- Final game version accessible via This Link

I have added a Technically changed version to the others. This Link No major change apart from the addition of the light beams in lantern and Candle mode. Keep pressing "T" till those options come around. --------------------------------------------------------------- Final game version accessible via This Link

Someone posted an old advert for Software projects. I enlarged and sharpened the picture. I adjusted the border. (I did not re-skew the picture) this normally has a detrimental impact on the resolution. I have edied the picture and inserted next years Calendar. 2nd file is a LARGE picture 1st file is the 2nd picture resampled to reduce the resolution

Officially for me the only versions of Manic Panic are the ones in post #112 here This Link The first being without the final Bonus, the second with the Bonus. The preference now being to use the 2nd version. As a technical extension, I might add a third version, with dark/light in it. (written) If I add the third version it has two more playing modes. Lantern and Candle These modes are in addition to the original modes. trainer/normal/expert/ace The Lantern mode plays with the blue Background and the rotate beam. Timer runs as normal. Can touch baddies and oxygen depletes The Candle mode plays with a black background. To me it is practically unplayable. Death on any baddy contact. In order to play the game with a black background. I have added into the timer the recognition of when Willy is moving or not. If Willy is moving left or right then the clock ticks down. If willy is jumping or falling the clock ticks down. If willy is static then the clock stops. While willy is static and the clock is stopped he can rotate the light beam. Perhaps someone can get somewhere with it like this ????? Note I say I might add a third version. Not I will add a third version Any third version I add, will be a novelty version. --------------------------------------------------------------- Final game version accessible via This Link

Previously I said Since this would always be known as the Pgyuri's effect, I see no point in carrying on further. This version V4 is the last version that I am doing, where the beam when static can be rotated by "H"-"k" one direction and "J"-"L" for the other Since this is a demo the black/blue background can be changed by pressing "enter" ( no keyboard de-bounce) This was just an exercise is see what I could do over a couple of days. Rotate.tap