Playing around.

[Norman Sword]

This file is mostly playable. It is NOT the finished product, and basically I am posting here for feedback.

 

In most caverns you are given far too much oxygen. The oxygen level has not been definitively set. 

 

No music routine playing. It needs music- It contains enough space for music routines.

 

No loader screen.

various screens from game.

Title screen

Intro screen -  16 wide / 9 high   = 144 tiles

Trainer screen - 22 wide / 16 high = 352 tiles

Peril size screen - 20 wide / 19 high = 380 tiles

Manic style screen - 31 wide / 16 high = 496 tiles  (normally 512 tiles)

Game playing screen - 31 wide / 23 high = 713 tiles 



 

 

 

After a week the file that was here- was deleted.

The file was downloaded 11 times.

7 posts in the week that followed.

 

;----------------------------------

 

 

The final Version which is playable is:-    This Link

 

 

 

Edited June 25, 2020 by Norman Sword

[Spider]

That's quite good fun!

 

I like the item collection sound and the collision effect too.

 

Note: Does not work in later machines (+2A/+2B and +3) as you only see the "Press enter to start your quest" message , the rest of the title screen does not appear. Fine in regular 128's though (toast-rack and grey +2 models

 

Talking of the title screen, I think some inspiration for that came from one of the first appearances if not the first of the Search loader, TechTed 48K specifically. :)

[Norman Sword]

I know exactly why this program will not run on other machines. It concerns the way the hardware ports are read. One reason I was reluctant to include the routine. (it stops judder- or helps to)  - I can remove and permit the judder instead.

Regarding the Title screen - Never loaded Technician Ted on a computer, so never seen the title screen. from that game. 
 

 

 

On a real (original)  spectrum it is possible to read the screen attributes. On the various updates the port/ula was changed and the ability to read the port was removed.

It is the reason several games will not run on newer hardware. 

 

 

 

Final comment on the hardware - I removed the routine that was added and was scanning a port. The original version ran a lot faster. And the speed made the Title screen Judder. Over several versions, it was deliberately slowed down. The difference in speed between what is seen and the original is considerable. The present slow version has no need for the port scanning routine. 

 

 

 

-------------------------------------------

 

 

Final version accessible via This Link

Edited July 20, 2020 by Norman Sword

[Norman Sword]

Technical info:-

The oxygen meter has a progressive rate of depletion. The lower the level the faster it moves.

The oxygen depletion caused by any of the normal death instances, causes a fixed amount of oxygen depletion.

What this means is a touch of a sprite at the start of playing a room, will have much more of an effect than the same touch near completing a room.

When the true oxygen levels are set. any contact/death noise near the start of playing a room, will tend to make it impossible to finish the room.

 

Each type of contact with a sprite/baddy/ or fall will deplete the oxygen by an amount that is fixed for each type of touch/fall.

 

Sprites can pass over any other sprites.

 

Sprites can pass over anything on the screen.

 

Willy is now drawn with a sprite mask

 

Sprites correctly colour in the background

 

Each room can be constructed of 16 differing tiles. A development from Manic 40 Miner

 

Rooms can have ignore tiles. A development from Manic 40 Miner

 

A proportionally spaced double height scroll routine is used.

 

Rooms can be defined as any size to fit the screen. (or part of)

 

nine baddy sprites per room

 

eight objects per room

 

Sprites can be mixed in any combination

 

old style events such as eugene/kong/skylab are sprite definable and not room events.

 

sprites can move diagonally. all sprites have a vertical and a horizontal component. (excepting kong/skylab/eugene)

 

 

------------------------------------------------------------------------

 

 

final version accessible This Link

Edited July 20, 2020 by Norman Sword

[Spider]

Had another play with this yesterday, once I get a bit of time hopefully later I'll post more feedback. :) I do like what I see so far though.

 

Regarding 'Search Load' without going into it too much, here is a small few seconds animated .gif to save you the bother, might have to click the image to animate it. As I mentioned in my 'why I thought' post above, why I thought of this. Its done during loading (no loading border) , pretty unique at that time. Mind you the loader gave me (and still does to be honest) headaches.

 

 

Regarding the +2A/B / +3 issue yes I suspected a port issue, have seen similar on other games. Floating Bus issue if I recall, . Interestingly or not there's a very simple (read: untested by myself but I should as I have a +2A and a +3) hardware modification that can reduce this issue.

 

Will you be uploading an updated version soon perhaps ? :) I'll retest the version I have anyway.

[Norman Sword]

Whilst I was aware of the technicalities of the loader from Technician Ted, never felt the need to load the game and watch it. 

 

The TITLE screen in this program (as above)  is about the tenth version. And the basis of what you see is simply the game it is based on.  A lot of screens have horizontally moving sprites. I duplicated a screen for the title screen. Then reduced the sprites to only one (Willy). Then removed the diagonals. then the colour. The overall plan was to give no clue as to what you will later see. For example after the mega long scrolling message the program will do a manic miner style flash past of all the screens that you have played (plus the first). It will not reveal un played screens. The more screens played, the more that are included in the demo loop.

I have no plans on uploading multiple versions, especially since I have tested the program without the port read on the +2a etc and it runs. 

 

 

The generosity of oxygen will make a lot of the screens very easy. This supply of oxygen will not end up as generous when I finalise the screens.  

When the program runs for each cavern it initialises a counter. For every game loop it increases the counter. When the portal is entered I can display the counter. Which is the time taken to complete a room. The final oxygen level will be set to the value of the counter plus a small amount. (the counter and its display output are one of the multitude of in program routines, which are in the program, waiting to be deleted on finalisation)  
 

 

[Spider]

Sorry to see the download has gone.

 

I've not had a great deal of time to do much with it, although I did like what I saw. The vertical guardian on the third cavern reminds me of Wanted: Monty Mole a little bit.

 

The main gameplay to change the collision to be the energy type bar vs instant life loss is an excellent idea too. :)

 

 

EDIT... I'm hoping the lack of others feedback has not dissuaded you from further development. :( Perhaps a screenshot or three would help. It does look highly promising! :)

 

If it means anything ( ? ) the 'screens$ examples' topic I posted mid-March that I wished to receive feedback for (as to which pattern was preferred, nothing more involved than that) has about 125 downloads in all and 0 replies.

Edited May 19, 2020 by Spider

[Spider]

:) Thanks for editing to add a selection of screenshots. Does (in my opinion anyway at least) draw more attention.

 

EDIT... Although I've not progressed very far, I was wondering how the collision detection worked, in that would it be in theory possible in your game to have a guardian pass through say a 'fire' object without trigging ? As we know with JSW/MM that means its counted the same as M.W catching said cell.

 

Only asking the above as it may allow some interesting design twists perhaps.

Edited May 20, 2020 by Spider

[Norman Sword]

The answer might surprise you.

Guardians do not interact with anything on the screen.

Guardians over fire cell- no response. 

Guardians over another Guardian- No response.
Guardians over graphics- No response.

;------------------------------------------

 

Major change in design for willy and the sprites

Manic miner and Jet set willy sprite logic:- (idealized model for sprite collision)

1) Willy is moved according to the program flow and keyboard activity.

2) Willy is drawn

3) The sprites are moved

4) The sprites are drawn.

5) For each sprite drawn the area behind the sprite is checked for pixel collision.

6) If a collision is flagged we exit and die

else

7) copy the screen to visible screen (pixels and attributes)

8) copy the master screen (the screen with graphics, but no sprites) to the working screen.

9) copy the master attributes to the working attributes

loop

 

JSw2 uses a very different logic for most aspects of the game

 

Jsw128 Vm uses a similar type of logic to jsw and MM but each routine is expanded and instead of part 8 we do a sprite and graphic refresh.

The graphic refresh is achieved by tracking every change that occurs on the screen. And storing every change. The list of changes is used to refresh the screen.

 

Manic panic;- does the following

1) Willy is moved according to the program flow and keyboard activity.

2) Willy's mask area is erased from the screen

3) The sprites are moved

4) The sprites are drawn.

5)

6)

> Willy is drawn to the screen, checking for collisions. Any collision is flagged 

7) copy the screen to visible screen (pixels and attributes)

8)

> the sprites are reverse drawn: e.g. Instead of drawing a sprite we copy the master screen to the working screen for the area the sprite was in

> willy is reverse drawn. e.g. Instead of drawing willy  we copy the master screen to the working screen for the area that Willy was in

9) copy the master attributes to the working attributes

loop

 

 The above is mainly concerned with sprite collision, of course lots of other bits and pieces. Concerning updates to conveyors, walls erased, item key flashes and portal  update, oxygen depletion etc. also take place.

The sprites themselves are treated as a moving graphic on the screen. They do not check for anything when drawn.

 

This brings collision detection more in line with JSW2. And using this method I could do eggoids from JSW2

 

 

The above is the basic logic change. The program itself does most aspects which can be described by the same action in differing ways.

 

 

 

 

For example the screen copy progression from version to version

 

MM and JSW a simple LDIR

 

JSW128Vk   raster copy using ldi (originally)

JSW128VL  stack copy
JSW128VM stack copy and the whole of memory reorganized to removed memory contention while copying. ( a very big change)

Manic 40 Miner stack copy and the removal of memory contention for screen copying.
Manic Panic stack copy and the removal of memory contention for screen copying.

 

 

;-------------------------------------------------------------------------

 

 

Final version accessible This Link
 

Edited July 20, 2020 by Norman Sword

[Spider]

Attached is a small "first few levels only" .rzx recording, specifically 00-05. This was performed an hour or so ago:

 

first_levels.rzx

 

Recorded in Spectaculator. Plays back fine in that and ZXSpin (0.7)

 

 

Thank you for your detailed explanation of the collision detection too. :) I followed most of it.

Edited May 20, 2020 by Spider