Resource centre for ZX Spectrum games
using Manic Miner and Jet Set Willy game engines
Archive of the
Manic Miner & Jet Set Willy Yahoo! Group
messages
|
|
|
|
|
Message: 4989
Author: andrewbroad
Date: 28/10/2005
Subject: JSWED: Andrew's comments (Part II: Manic Miner)
(continued from Message 4974)
####################
Part II: Manic Miner
####################
9 Editing Games
===============
JSWED doesn't recognise the Software Projects edition of Manic
Miner - specifically the TAP version I downloaded from...
ftp://ftp.worldofspectrum.org/pub/sinclair/games/m/
ManicMiner(SoftwareProjectsLtd).tap.zip
...
where "Bytes: mm2" has a length of 32767.
It also doesn't recognise MIRRORMM.TAP from Party Willy. By what
rules /does/ it recognise a MM game?
It would be nice if JSWED allowed the user to edit:
* the columns of Eugene, solar power, Kong Beast, switches and the
wall that the first switch opens;
* the colour-attribute of solar power (36262), and the colour-
attribute that triggers air-loss (36228);
* which horizontal guardian gets its right-boundary edited to what
value by the first switch;
* the position of the swordfish;
* which room has the swordfish-behaviour and shares the title-screen
picture.
These values are hard-wired into the game-engine, so they affect
both Kong Beast rooms, &c.
--------
9.1 Game
--------
This could support other patches, such as:
* those documented in TECHNICA.TXT of _Manic Miner: Neighbours -
Allana Truman_;
* the changes that SPECSAISIE MirrorMM makes to Kong-Beast rooms,
Skylabs and solar power;
* switching between the Bug-Byte and Software Projects game-engines.
And how about a function to upgrade a MM game to JSW64?
-----------
9.3 Sprites
-----------
It might make more sense to be able to edit the special graphics
(swordfish, plinth, boot) here, rather than having them tucked away
in "Portals" in the rooms they're actually stored in,* which is a
less obvious place for the lay user to look.
---
* usually Rooms 0, 1 and 2, although for games with the "Specials by
room" patch, JSWED should allow the special graphics to be moved to
other rooms (or free areas of memory), as I did for MM:N-AT.
And what's happened to Import and Export? These functions should be
included, although they're more complicated for MM than for JSW, as
MM stores guardian-sprites interleaved with room-data.
Also, MM stores a horizontal-guardian's right-facing sprites in the
top half of the sprite-page, while JSW stores the left-facing
sprites first (except for Willy), so it would be useful to have a
function to swap the two halves of a sprite-page while editing, and
a checkbox to swap the two halves when importing and exporting.
-------------------
9.4 The Room Editor
-------------------
9.4.3 Editing cells
-------------------
JSWED should allow more than one item at the same coordinates.
JSWED should allow the user to sample any colour-attribute in the
playing-area (recognising if it matches the colour-attribute of a
block-type), and then place that colour-attribute in the usual way.
Sampling colour-attributes would have been particularly useful when
I designed Room 19 of MM:N-AT, where the top half is an intricate
mixture of arbitrary colour-attributes and defined blocks (I
generated the picture using BMP2SCR EXP; then I wanted to sample
arbitrary colour-attributes so that I could assign them to the most
appropriate block-types to make it playable, but I had to do it
visually, with several wrong guesses which had to be undone).
?+-?????????????>??....??????..?
?---??????....????.?..?...???*>>
||++|...??....??*?...*...*....?.
||--|..?........*?...*....**....
||.+?..??.???...??*|??.....||?*|
*...?...???..?...????...........
.........-..???..????##?????????
...>>...?..?.?????$??##?????????
|.......!........!..............
|-..............................
|*-..........................*..
|..-........>>>>>>>>>|*+*>>>>>||
$...-......_...........$......$|
..._.-.....*....................
...*$.-....*>...................
|>>>>>>>>||>>>>>>+>>>>>>>>>+>>||
Ningwaar!
Editing the conveyor-animation (c:Convey) should not place conveyor-
blocks under the conveyor-animation, as the MM room-format allows
blocks of any type to be animated (although this can still be
achieved with JSWED by placing the other blocks /after/ placing the
animated conveyor).
Having a 0-length conveyor-animation corrupts the screen during
play. So the user should be encouraged to have at least one block
that is conveyor-animated, even if it's just a background (Air)
block.
JSWED should allow the conveyor-animation to be shifted downwards by
up to 5 pixels, as allowed by Bits 2:0 of Offset 625 (usually 000,
but can represent a downward shift of up to 7 pixels). [Edit: I
later found out that this can be done in Conveyor options (Alt+C),
but that whole menu seems like an unnatural separation.]
The vertical positions of portals, items and guardians could also be
pixel-edited, but when they straddle three character-rows, MM only
writes the top four colour-attributes - not all six as JSW does for
horizontal and vertical guardians. Perhaps another MM patch is in
order?
9.4.4 Room options
------------------
> * General: Allows you to set the border colour, room title andToo much copy and paste here, although a patch to set Willy's sprite
> (in 128k games) Willy's sprite.
in 48K MM would be nice! :-) And you can edit the air-supply,
although I dislike having to edit it as a number, rather than
visually as in my Manic Miner Screen Editor.
JSWED should allow invalid air-supplies, as in MM:Buddha (Rooms 10 &
19), with a stern warning to the user. When I viewed these rooms in
JSWED, it just showed valid values for the air-supplies.
Shapes
------
It's nice to be able to edit the pixel-patterns and colour-
attributes of the block-types together (unlike in the JSW editor),
but the preview of the shape should show the colour-attribute as
well as the pixel-pattern.
Unfortunately, JSWED has completely ignored the problem of attribute-
capture:
* The MM room-format represents the screen-layout as 512 bytes, each
of which is a colour-attribute (which usually identifies a single
block-type whose colour-attribute and pixel-pattern are defined
later in the room-data). This causes a problem when two block-types
have the same colour-attribute.
The problem: If you change a block-type's colour-attribute to that
of another block-type and click "OK", then all occurrences of the
block-type that is defined later in the room-format will turn into
the block-type that is defined earlier (e.g. all crumbling blocks
turn into water-blocks if you give Water the same colour-attribute
as Crumbly, or if you give Crumbly the same colour-attribute as
Water).
Once attribute-capture has struck, there's no way to retrieve the
occurrences of the block-type whose colour-attribute has been
captured, other than reloading the game-file. Even if you set the
colour-attributes back to what they were, the MM room-format has no
way of distinguishing which blocks were of which type. JSWED's Undo
function only seems to restore the top half of the screen-layout in
this situation.
MMSE's solution is that whenever you set the colour-attribute of a
block-type, it checks whether any other block-type has that colour-
attribute, and if so, it asks "Do you wish to update the screen-
layout anyway, at the risk of attribute-capture? (Y/N)". If not,
then the user must fix the colour-attributes manually.
There are actually two cases that the MM editor needs to check for,
whenever the colour-attribute of a block-type is changed:
1. The NEW colour-attribute is already defined for another block-
type: updating the screen-layout automatically will lose the
distinction between the two block-types.
2. The OLD colour-attribute is also defined for another block-type,
i.e. two block-types that used to have the same colour-attribute now
have different ones: updating the screen-layout automatically will
replace /all/ blocks of that colour-attribute.
JSWED could go a step further than MMSE, and check whether there
actually /are/ any occurrences of the new (Case 1) or old (Case 2)
colour-attribute in the screen-layout, because user-intervention is
only needed if there are.
9.4.5 Conveyor options
----------------------
As in the JSW editor, it seems unnatural to separate the pixel-row
of the conveyor-animation, and whether conveyor-blocks are `off' or
`sticky', from editing the conveyor itself.
I would prefer JSWED not to treat "animated conveyor" as a cell-
type, but to have a separate mechanism for setting the position of
the conveyor-animation (including its pixel-row) and the direction
of the conveyor (left, right, off or sticky), without placing
conveyor-blocks under the animation (or provide a checkbox to do so).
9.4.6 Item options
------------------
There's a bug in printing the item's pixel-pattern when you first
arrive here: the leftmost pixel-column is missing (not to mention
the trailing pixel-column bug that is common to all places in JSWED
where you edit 8x8 graphics).
Also, it would be nice to indicate that each item's ink-colour
applies only to the zeroth time-frame (is a means of putting the
items' colour-cycling in the phase you want), and that the only
valid INK-values are {3,4,5,6}.
If a room has fewer than five items, you can still see Items 1 to 5
here. It should indicate which ones are missing.
There's no way of telling which item that you see on the screen
corresponds to which item you're looking at here, and this is
important to those of us who care about the phase of the colour-
cycling. Perhaps from here you could view the position of each
individual item - and edit it, which would allow two or more items
at the same character-square.
------------------
9.5 Guardians page
------------------
I would prefer to see the vertical guardians as a separate list
numbered from 1, rather than bolted onto the HG-list and numbered
from 5.
If you delete a guardian, you should be able to press Undo. It's all
too easy to click Delete instead of Edit.
Theoretically you can edit a horizontal guardian's row by pixel, but
if it does straddle three character-rows, its colour-attribute will
be written to the top two character-rows only (unlike JSW which
colours all three character-rows).
Clicking "Add guardian" when there are already four HGs in the room
should give an error-message rather than do nothing.
Adding a guardian should allow you to set its start-position before
taking you to the guardian-editor. I always set the {row of a
HG/column of a VG} before I edit its bounds.
Adding a horizontal guardian to a Skylab room doesn't seem to work
properly (it appears as another Skylab), and when you visit "Skylab
Landing Bay" in the original MM, it reports two HGs as Guardians 2
and 3!
Sometimes when you click "Add guardian" in a room with VGs, it just
creates a VG without giving you the choice of Horizontal or
Vertical, and there's another bug whereby an extra "Horizontal"
appears in the guardian-list, but you can't click on it.
-----------------
9.6 Portal editor
-----------------
Setting the position of the portal doesn't /appear/ to work, no
matter how many times you left-click or press Space. But when you
edit its colour-attribute, it draws the portal at the position you
set, without removing the portal from its old position.
If you set the portal to flashing, it should be shown on the screen
as flashing - especially important for portals, as a flashing portal
takes you to the next room even if you haven't collected all the
items.
> G Edit the portal graphic and the Eugene graphic"and the Eugene graphic" -> "and, if applicable to the current room,
the special graphic (swordfish, plinth, boot or Eugene)"
JSWED should warn the user if the room has both vertical guardians
(Offsets 733 to up to 760) and a special graphic (Offsets 736 to
767), and should allow both to be edited, with a clear visual
indication of the overlap.
JSW should have a checkbox to allow a jump to be induced upon
entering the room (set Offset 619 to 1).
The keypresses in the manual should be grouped by function rather
than sorted alphabetically.
-----------------
9.7 Screen editor
-----------------
When importing a .SCR file, JSWED should allow the user to select
which third of the screen is to be imported.
It would be nice to have another screen (for JSW as well as MM): a
full-screen scratchpad (or allow the user to create as many
scratchpads as (s)he likes) which is not saved in the game-file, but
allows the user to draw big graphics. Whenever you save the game,
JSWED should warn you about any unsaved scratchpads and offer to
save them in separate files (.SCR, .PNG, or insert a SCREEN$ into
the game's .TAP file - in which case it /is/ loaded and saved with
the game).
Once we have scratchpads, it would be useful to be able to copy any
16x16-pixel square (or more than one at once), which can then be
pasted into the sprite-editor.
======================
10 The Guardian editor
======================
10.2 Editor overview
--------------------
Pretty much what I expected from the JSW guardian-editor, complete
with the annoyance that, while editing bounds, clicking "-" on "000"
goes to "112", but clicking "+" on "112" does nothing, and JSWED
sometimes crashes after editing a guardian (especially a VG, but
sometimes also a HG).
--
Dr. Andrew Broad
http://www.geocities.com/andrewbroad/
http://www.geocities.com/andrewbroad/spectrum/
http://www.geocities.com/andrewbroad/spectrum/willy/
|
|
|