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: 4974
Author: andrewbroad
Date: 22/10/2005
Subject: JSWED: Andrew's comments (Sections 6.6--6.9; Chapters 7, 8)
########################################
Part I: Jet Set Willy (JSW48 and JSW128)
########################################
6 Editing games
===============
(continued from Message 4969)
I've just found an undocumented menu in "Game" with the following
options: Clear rooms, Clear guardians, Clear sprites.
"Clear rooms" should clear everything about each room (I notice that
conveyors, ramps and block-graphics aren't cleared). In other words,
the 256 bytes should all be set to 0, with the exception of Offset
240 which has to be 255 to represent an empty guardian-instance list.
On the other hand, "Clear rooms" shouldn't delete the items; there
should be a separate option "Clear items" to remove all items except
one (since it's impossible to encode a JSW game with 0 items).
"Clear items" would be useful for testing the end-game sequence.
BTW, the table on p.12 of the manual still says "O | Toggle object
under the cursor when SPACE is pressed" instead of "I | ...item...".
Also, I wish JSWED would print coordinates for everything, like JSW
CK. This is particularly important when setting the column of a
rope, as some columns cause the Rope-Teleport Bug; the standard
column for a rope is 16, so I want to be able to see that I've
centred it exactly.
JSWED could do with a pause-key, so that you can single-step through
the time-frames of a room's guardians if necessary. And a reset-key
to return to the first time-frame would be useful for previewing
arrows.
-------------------
6.6 Teleport editor
-------------------
You should not have to sacrifice a room to the teleport-code! Any
unused memory will do (JSW:LOTR uses the sprite-page at BF80).
JSWED should list all the teleporters in the game, or allow you to
visit the rooms with teleporters in turn.
Clicking on a teleporter should allow you to view its destination as
well as change it, and to visit its destination just as you can
visit the destinations of regular room-exits using the four arrows.
Depicting a teleporter as two vertically-stacked character-squares
is inaccurate:
................................
................................
...**...........................
.............$||||$.........
............||....||........
...**........|||$......$|||.....
...........||$............$||...
.........||$.................||.
........|.....................$|
.......|.......................|
.......|.........-...-...-...-.|
...../|------....T.............|
..../.|..........T.............|
.../............---------------|
../............................|
>>>>>||||||||||||||..|||||||||||A Long-expected Party
From left to right, you have to walk into the T so that no part of
your body is to the left of the T before it teleports you. But from
right to left, you only have to touch the edge of the T to be
teleported.
This behaviour is akin to portals in Manic Miner, so it would be
much clearer to depict a teleporter as a 2x2 character-square:
................................
................................
...**...........................
.............$||||$.........
............||....||........
...**........|||$......$|||.....
...........||$............$||...
.........||$.................||.
........|.....................$|
.......|.......................|
.......|.........-...-...-...-.|
...../|------....TT............|
..../.|..........TT............|
.../............---------------|
../............................|
>>>>>||||||||||||||..|||||||||||A Long-expected Party
I discovered the following bug in JSWED: I visited a room in the
Teleport Editor, placed a teleporter there, then went to the Room
Editor to place some floor-blocks in the room to mark the location
of the teleporter, and remove the guardian-instances that would have
collided with them. When I returned to the Teleport Editor, the new
floor-blocks were gone and guardian-instances were back!
Evidently the Teleport Editor had retained an out-of-date copy of
the room. It can be refreshed by leaving and reentering the room,
but JSWED should be more on the ball about things like this.
-------------------------
6.7 Start position editor
-------------------------
If you change Maria's vertical position, this does not change the
rows at which Willy triggers her to point.
It would be nice to be able to edit which column in the Master
Bedroom triggers Willy's toilet-run.
I can't get safe restart-positions to work. I started with a fresh
copy of the original JSW, I ticked "No infinite death" in Game, I
set Willy's initial position again, I set safe restart-positions in
Rooms 33-35, I verified that the three green Willys and the white
Willy appeared correctly in JSWED after refreshing the rooms, but
when I saved this game and played it, it just crashed when I died in
all three rooms.
---------------
6.8 Font editor
---------------
The manual doesn't mention that this doesn't apply to JSW48. But
Goodnite Luddite has a custom font (not recognised by JSWED), so
JSWED should be able to recognise or apply this patch just as it can
already recognise or apply the teleport-patch.
The Font Editor doesn't update its display of the character-set as
(or even after) you edit each character.
-----------------
6.9 Screen editor
-----------------
A very good job overall - much nicer than drawing the screens in
Leonardo as I used to! :-)
When editing the colour-attributes of the bottom third, JSWED should
display the text and player-sprite from the game it's editing (it's
currently hard-wired to use the ones from the original MM/JSW).
6.9.1 The Zoom window
---------------------
It would be nice to be able to toggle pixels by clicking in the zoom-
window, since "moving the mouse by one pixel at a time is quite
fiddly" [Section 6.9.2], and mouse-control is much faster than
keyboard-control in my experience of editing sprites and "shapes".
6.9.3 Editing attributes
------------------------
Editing the colour-attribute is much nicer here than in the Room
Editor! :-)
But it would be useful to be able to sample a colour-attribute by
clicking on a character-square in a special mode (or by pressing a
special key), which would tell you the INK, PAPER, BRIGHT and FLASH
for that square, and then allow you to apply that colour-attribute
to other squares in the usual way.
6.9.6 Undo
----------
Saving the game (F2) should set the undo-point too (and everywhere
else in JSWED that has an undo-key). Maybe even have a special key
you can press to set the undo-point without having to leave the
screen.
6.9.7 Import/Export
-------------------
Export: Changing the directory in which to save a screen doesn't
work. It just saves it in the directory it starts in.
When you export a SCREEN$, is the file in +3DOS format?
=====================
7 The Guardian editor
=====================
When you edit a guardian-class, how do you know which other rooms
will be affected? How can you tell if a guardian-class is unused in
the game before you overwrite it?
JSW CK can generate a list of all the instances of a given guardian-
class, allowing you to immediately select one for editing, and I
would very much like JSWED to be able to do likewise, as one of the
highest priorities of all my suggestions.
SPECSAISIE has a function GuardianClassUseJSW which looks up all
instances of a guardian-class, and another function
SpritePageUseJSW, which looks up all guardian-classes that use a
given sprite-page. But these only work for JSW48.
I must confess I'm particularly proud of the way JSW CK handles
guardian-classes. It gives you direct access to the guardian-class
table from outside the Room-Editor, and you can quickly browse
through the table to see each class's guardian-type, sprites and
colour.
You can then look up all instances of a guardian-class, and select
one of them to edit the guardian-class with respect to (you can also
select them directly from a room's guardian-instance list). You can
then edit the path-data (with a clear separation of what belongs to
the guardian-class and what belongs to the guardian-instance).
And JSW CK allows new instances of a guardian-class to be created
from either direction: from the room (if you know the guardian-class
number) or from the guardian-class (if you know the room-number).
-----------------------
7.1 On Guardian Classes
-----------------------
jswed.pdf
> In Jet Set Willy games (other than JSW64), guardians in a room areActually, it's 127 entries for a regular guardian-class table (GC 0-
> drawn from a table of guardian classes, with up to 63 entries
> (Softricks games have 127 entries in their guardian table;
126; GC 127 can't be used because it clashes with the item-count). I
know Softricks JSW uses a double guardian-class table - 256 entries?
-------------------
7.2 Editor overview
-------------------
JSWED should divide the values of vertical position, vertical step
and vertical bounds by 2 before it presents them to the user, so
that they're in pixels per time-frame. This is what JSW CK does -
the fact that the pixel-row has to be multiplied by 2 for the
internal representation is completely transparent to the user.
Sprite
------
This should be settable to any sprite-page in memory, from 0000 to
FF00. A direct link to the Sprite Editor (as in JSW CK) would be
useful here, rather than the user having to memorise the address.
right of Y
----------
The value seems to go haywire if you try to increment it beyond 126.
So I deleted the value, typed "1" and pressed Enter, and JSWED
crashed.
L/R? (Vertical guardian)
----
This should be called U/D? for vertical guardians.
This field doesn't seem to interact properly with the vertical step
("right of Y"), which should be +ve if the VG goes down initially,
-ve if it goes up initially.
Should this field even be there at all for vertical guardians? If
so, the table on p.16 of the manual needs to be fixed (currently it
says "L/R? | All except vertical").
L/R? (Arrow)
----
You have to leave and reenter the room before JSWED shows the arrow
going in the new direction.
When you change the direction of an arrow in JSW CK, it
automatically adjusts the start-column from x to 287-x (mod 256), so
that the arrow appears on the screen at the same time-frame (proof:
Message 1867). This formula is extremely useful when designing rooms
where left and right arrows appear at regular intervals.
Animation
---------
JSW CK presents this as a binary animation-mask (00, 01, 10 or 11
for horizontal guardians, with a separate flag for whether the
guardian is bidirectional; 000-111 for vertical guardians). There
are only 3 bits for the animation-mask, so why does JSWED allow
values > 7?
Bounds
------
"-" from 0 goes to 31, but you can't go "+" from 31.
JSWED crashed when I tried to type in a left-boundary.
Fast (Vertical guardian)
----
It would be better to call the checkbox "Slow" and invert its
meaning, for fast animation is the norm (changes every time-frame,
whereas slow animation changes every two time-frames).
Rope pos
--------
What is this? The initial position along the rope's swing? It has no
visual effect when I edit this. What are the units?
It would be useful to have a "Default" button for each of "Rope
pos", "Rope len" and "Rope swing", to restore them to their standard
values (Guardian-Class 1 in the original JSW).
Bitmap (Arrow)
------
JSWED should show all three rows of the arrow so you can actually
see what it looks like as you edit it. JSW CK does this.
When I right-clicked the bitmap to bring up the popup-menu, in the
hope of finding lateral-inversion and shift/rotate facilities, it
appeared for an instant, then JSWED locked up.
----------------
7.5 Rope editing
----------------
jswed.pdf
> The rope length can be 1-32Actually, JSWED allows 0-255. JSW CK allows 0-42 (it does not allow
the rope to go off the bottom of the screen).
> Unless you are using the (new) "adjacent ropes" patch, ropes mustThis text belongs to Chapter 6, as this is a guardian-instance issue
> be stored last in a room, or be followed by an arrow, or by an
> instance of a blank guardian such as Guardian 0.
rather than a guardian-class issue.
It's worth stating (in Chapter 6) that the guardian-instance list
must be ordered as follows:
1. All horizontal and vertical guardians
2. Rope
3. Arrows
(The arrows must be last because a HG or VG will kill you if it
collides with an arrow, and the rope will pick you up if it collides
with an arrow, but an arrow will only kill you if it collides with
white-ink pixels.)
=============
8 Good Advice
=============
> 1. Don't put anything in the path of a guardian.It's okay to put items in the path of a guardian, as the items are
drawn after the guardians (and will be collected if they collide
with a white-ink guardian).
A JSW author should be aware of the order in which objects are drawn:
1. elementary blocks (background, floor, wall and static nasty);
2. ramp and conveyor
3. the player
4. guardians
5. items
6. Maria or the toilet
(http://www.geocities.com/andrewbroad/spectrum/willy/collision.html
has a much more detailed explanation of collision-detection)
> 3. If you have white background INK, any objectsitems
> in the room will be automatically collected on entry to the roomExcept for any items on non-background blocks that don't have white
> (see swimming pool).
INK.
> 4. Do not have two cell-types with the same attributes.But there are some useful combinations, including:
* background = ramp (springy platforms)
* floor = ramp ("Out on a limb", "Rescue Esmerelda")
* floor = conveyor
* wall = ramp
* wall = conveyor
* ramp = conveyor (as noted in 5.)
> In particular, don't make other cells the same colour as Fire.Another thing to avoid is having white-INK Fire in the case that Air
and Fire have the same PAPER, BRIGHT and FLASH.
> 6. Avoid having a guardian at the top of the screen above a gap atThis should read Fire-blocks, not guardians. And it can often be
> the bottom (see right-hand half of Under the Roof).
useful to block gaps in this way to eliminate infinite-death
scenarios, or to create a quirky challenge.
> 7. ...do not allow an arrow to pass through a rope (especially notArrows must be after the rope in the guardian-instance list, then
> a white rope).
it's perfectly safe to have an arrow pass through a non-white rope.
But if an arrow collides with a white rope (or any other white-ink
pixels), it kills you.
> Note that putting the arrow after the rope in the guardian listguardian-instance list (to avoid possible confusion with the
guardian-class table)
> 8. Never allow guardians to overlap.Unless you're fond of time-limits, or they overlap in such a way
that they'll never collide (as in "The Forgotten Abbey").
> 9. Objectsitems
> on top of other cell types (floors, walls, etc.) cannot beUnless you have an arrow or other white-ink guardian collect them,
> collected.
or unless it's a crumbling block (which is a very effective way to
prevent items from being jumped up for from below).
I would add more advice, including:
10. Eliminate infinite-death scenarios as far as possible (unless
the player has to do something really stupid, such as jumping into
an unfamiliar room when they should be walking in, or falling off
the bottom of the screen from a height of five or more character-
rows).
11. Quirky features are a pathway to many abilities some consider to
be unnatural. Learn to recognise them, and you'll be able to spot
any unintended loopholes in games. Learn to use them, and you will
achieve a power far greater than any Jedi.
12. Playtest every room thoroughly, especially all possible exits
from the room. If you make even a trivial change to a room, never
forget to playtest it again.
13. Do a complete playtest to make sure the final revision of the
game is toilet-completable before you release it.
14. Save your work regularly by pressing F2, especially before using
the Guardian Editor, which is notoriously prone to crashing.
15. Hard-drives fail, floppy disks get corrupted, CDs become
unreadable, buildings burn down and files uploaded to the Internet
get removed, but if you regularly save your files in three
completely different places, then the probability of losing your
game is very slim.
--
Dr. Andrew Broad
http://www.geocities.com/andrewbroad/
http://www.geocities.com/andrewbroad/spectrum/
http://www.geocities.com/andrewbroad/spectrum/willy/
|
|
|