Norman Sword

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

Provisional music, which will more than likely stay. : old file attached here - deleted - down loaded 4 tiles --------------------------------------------------------------- Final game version accessible via This Link

Did you miss that statement.

Nothing to do today---- so i wrote the music. --------------------------------------------------------------- Final game version accessible via This Link

Back to the theme of playing around. I wrote the screen copy basics, when I was showing how I would display Perils of Willy. Those screen copy basics were modified into JSW128 VL demo . And expanded again in JSW128VM Using the screen copy routine that was eventually written for JSW128VM. I expanded the data and added some sprites. I designed and wrote a sprite draw routine, and then added my own sprite movement routines. I then added keyboard routines and fleshed it out with a game control part. All this code is new. It was at this point a few days down the line, that I encountered a major problem in the design of the overall program. Up to this point the movement of graphics and the speed of screen update was ok. However as I added more and more routines it became very noticeable that the stack copy was having a serious problem with regards how it updated the screen. The bigger screen was introducing a phase lag across one raster line and only one raster line. The Glitch this introduced had not been noticed before, and once it was noticed i could not carry on and leave it. At first I puzzled over the nature of the glitch, but eventually I worked out the exact nature of what the problem was. The extra size of the screen was just enough to render the method used as unworkable as far as I was concerned. I wrote several differing versions of the stack copy, and the problem would seemingly not go away with the fastest methods I could write. The problem was not speed but the method of implementation. I could cast aside the method I was using and write a bigger routine that used more data. Or use a true raster line stack copy via the Ytable. The problems become the negation of speed with repeated look ups of data or the vast amount of data and space needed for rolled out stack copies - None of these were to me an option. So after about four/five days from the start of doing these routines and having a working couple of rooms to play. I contemplated pulling the plug. The glitch that I was seeing was not acceptable to me. The update method had a serious flaw, and I was struggling to overcome this flaw. By the end of the first week, I was about to give up. I decided to scrap the method I was using. My assembler was now littered with dozens of switches and options that implemented various differing methods of stack copy. I tried a new method and copied a lot of macros across and changed the basic method I was implementing. It seemed like every other block of code I had written. I knew the method was not as fast. Yet when I assembled the code and ran it. The glitch had gone. Which proved it was the method implemented originally that was wrong and all the updates and changes could and did not fix it. I added a few more rooms and then added game control. By the end of the 2nd week I had more or less what is seen in these demo's. What I have done in the weeks since is refine the code and re-write some of the routines. In some ways I wish I had not written every routine from scratch. It was just easier to say to myself, what do I want. Then write the routine. It seemed pointless using someone else's code that did not do what I wanted. As an example:- name a version of JSW that permits sprites to cross the background. The only answers that I am aware of are JSW2 and JSW2+, the third answer is JSW128VM. I knew from JSW128VM that it was not an easy change. And I also knew from JSW128Vm that the changes in that version did not go far enough. The whole sprite usage in JSW2 and JSW2+ was sufficiently different, that I could ignore that. So in the end it was just quicker to write all my own routines. The stoppage at this point concerns implementation of Music. Not something I can do. I can write any number of music routines and play the music in my own routines. But I do need a simple file to implement the music as data, along the lines of O3fs,o3e,o3e,o3f,o3a Which reads as Octave 3 F sharp, octave 3 E, octave 3 E, Octave 3 F and finally octave 3 A. Given a music score in the fashion written above I can happily write the music routine. Asking me to write this file myself is not going to happen soon. --------------------------------------------------------------- Final game version accessible via This Link

The biggest versions of JSW in 48k are in descending order JSW2+ around 147 rooms - expanding the game +83 rooms JSW2 around 134 rooms - expanding the game +70 rooms JSW128 VM 128 rooms - expanding the game +64 rooms then the next best is around 75 rooms - expanding the game +11 rooms. JSW 60 rooms designed to store 64 expanding the game -4 rooms

Plodding along, writing various versions. Each new version with an inclusive compression routine for the data. The data is already compressed into nibbles and the various room sizes are creating problems. The problems stem from the amount of code needed to compress and then expand a room that does not have a fixed size. The normal course for me, would be to write a program that compresses the data and then outputs a file that I can assemble in my assembler. This means the program only stores the compressed data, making it very difficult to change by anyone but me. I have decided in this version to leave the data stored as nibbles. Then after loading the program will compress the nibbles data and then discard it. This does in theory make the data editable using a simple hex editor. The compression of the data is handled by the program, so the compressed data does not need to be edited. This does mean that only the raw file is editable, but that is still better than editing the compressed data. I know that the data compression on JSW2 was handled by a few lines of basic code. That is code written in CPC Basic. Each room was designed and then sent from the CPC across to the Tandy as a file containing data statements. If the file needed changing the room would need to be redrawn and sent again to the Tandy or the compressed data would need to be edited. In some rooms the redesign, only needed an odd byte changing. Perhaps after finding a platform needed extending or shortening. So it was quicker to edit the compressed data. That is why some rooms are not optimised as well as they could be. The above is the reason I am trying to keep the data in a simple format. So that simple edits can be performed without resorting to editing compressed data. The rooms are drawn by me in hex. I want to keep that simplicity. On the other hand I could forget about doing any of the above and just carry on with the very limited memory available. --------------------------------------------------------------- Final game version accessible This Link

I had a good session playing this last night, and I daresay I will again tonight. I really like it, the graphics just seem eye-popping on a 4k monitor that I have my Next connected to, it just looks wonderfully colourful. In terms of what you say above, can the game be completed on 'normal'? I assume so, so apologies if that is a daft question. The File(s) are preliminary layouts, and I can do a lot of them. I have not tried all of them. I am concentrating more on what I can do, before I persevere with playing them to finality. So do not be surprised if you find a level impossible or seemingly so. It might well be so. I note too that the level designs are to be found in some of your other MM based games, the flowerpots etc. The diagonal moving sprites really break things up too aesthetically as well as gameplay wise - unless that is from a different version of MM I have played, there are so many, if so then sorry :-) The diagonal part is not unique. It was done in JSW2, it is done in JSW128VK etc. What is unique is the ability of sprites to cross over the background graphics. Not done with any other version of JSW - (I am Ignoring JSW2 because I know that that can do a whole host of things that JSW can not). Also apart from my version of manic miner, I am not aware of any version that uses a sprite mask on the 48k spectrum The Flower pots were drawn as Greek urns. The graphics are taken from Manic 40 Miner. For those graphics I designed and wrote an editor. I have now swapped over to windows 10 pro, which will not let those programs run , so unless I go back to my old computer, all room designs and graphics are done by simply typing out the data. I re-read what I had written above about the screen design in Perils of Willy earlier in the thread, and realise that it is not applicable here in a way because those screens themselves were designed originally back in the 80s when that game first came out, so have not been too altered in terms of difficulty compared to the modern mods of JSW and MM that can be so hard. Personally I think the system you have employed here is excellent and caters for everyone. I am not sure what the scrolling messages add to the early screens that a static message like a room name wouldn't add? If you read the mega long scrolling message and start playing the 1st,2nd ,3rd cavern. You will see that they are a continuation of the story. On the first cavern the scrolling message is around two and a half screens in width, difficult to place anything of that size and nature on the screen without it becoming over bearing. The larger screens take up all bar the bottom line. That is 23 screen lines, no room to place a room name. The messages do not use any other memory that is not contained in the room file. e.g. the sprites that are not used in that room are replaced with scrolling text. I do like too in later screens where the whole screen apart from the bottom 2 lines are deployed as gaming area, The playing area is the full screen bar one line on the bottom and one column on the extreme right. The area updated on each game loop is the full screen. something different from MM but it looks really good visually and gives more room for design. As for the size of the memory used above, is producing a 128k version a possibility? I do not even look at 128 spectrum versions of any game from that era. The 128k spectrum did not exist when Manic Miner/Jsw/jsw2 where written. I write only on hardware that was available at the time these games were written. Any program I write COULD have been written and release when the originals were released. The reason I ignore other hardware is because these programs are written solely for my enjoyment. With the main constraint being that they must run on the original spectrum. When writing a game in 48k the limitations of the hardware the processor and memory, dictate what can be done. Hope that this is constructive for you. ;=============================== My text is in Blue in response to text in Red. I do appreciate you taking the trouble to comment. --------------------------------------------------------------- Final game version accessible This Link

I have just run the file on Torinak - no problems. If you had read the start of this post and the responses I made. You will have seen that the original file used a port that when scanned can cause a problem with any spectrum version that is not the original. Implication being Torinak is not specced as an original spectrum. --------------------------------------------------------------- Final game version accessible This Link

Version beta 3. Not changed a great deal, that can be seen. But underneath the exterior is a lot of code change. This looks pretty much the same as before. Only casual difference would be that on loading it now displays the word "Trainer" on the title screen. Plus a change in the scrolling message about the version and the date. Game changes. While the title screen is displayed , pressing the keyboard letter "T" will change the word "Trainer" to "Normal", another press of "T" will change the word "Normal" to "Expert". And yet another press will change the "Expert" back to the original wording of "trainer". Those three words are describing the game play. The graphics of each room will not be changed by the differing level of play but other changes will take place. 1) trainer mode: Here the oxygen level is set to full, and the game depletes the oxygen counter very slowly. The number of sprites in a room is reduced by two. The game can not be completed in this mode. 2) Normal mode. Here the oxygen level is set to a level where the room can be completed at a casual pace. The oxygen depletes a lot faster. The number of sprites in a room is reduced by 1 3) Expert mode. Here the oxygen level is set to a level where the room can be completed at a brisk pace. The rate of oxygen depletion is very fast, Now all contacts with sprites/baddies/fall etc will result in Willies demise. Each mode has its own high score. The trainer mode will give excessive score due to the remaining oxygen left at the end of each cavern. The above is an outline of what is intended.... The rooms themselves have not be fully defined. in terms of graphics/sprites/events/ and the oxygen level At present around 25 screens:- that, like every other aspect, is subject to change. -------------------------------------------------------------------------------------------- Addendum:- The size of the file is a good indicator of how much ram is set aside for those giant screens in memory. The real screen is 6656 in size. For this game variant we also have a Working screen and a Master screen. Those 3 screens are using 19968 bytes of memory. So nearly 20k is dedicated at the start for game screens, leaving just 28k from the 48k for the program and all its data. I am at present at the point where I need more memory to do the things I want. I will probably do a major memory reconfiguration and data compression. (something that will not be seen) ------------------------------------------------------------------------------------------- Deleted obsolete download --------------------------------------------------------------- Final game version accessible This Link

I have had a thought which I will implement tomorrow sometime. I will set three levels of play. 1) trainer- How willy imagines he will breeze through the caverns. Lots of air . 2) the reality version, Just enough air to get through a cavern with no sight seeing on the way. 3) Deadly. The same time limit as 2 but where every contact kills willy instantly. - With only versions 2 and 3 actually getting to completion of the quest, Addendum 6 hours later (after a sleepless night, and I am very tired) I have implemented the 3 modes. "Trainer", "Normal" and "Expert". (terminology as used in the game text) --------------------------------------------------------------- Final game version accessible This Link