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: 4969
Author: andrewbroad
Date: 21/10/2005
Subject: JSWED: Andrew's comments (Chapter 6 to Section 6.5)
(continued from Message 4955)
########################################
Part I: Jet Set Willy (JSW48 and JSW128)
########################################
6 Editing games
===============
Pressing F2 to save the file is rather dangerous if you have loaded
a JSW game with no intention of altering the file, and press F2 by
accident. I just managed to do this to my master-copy of the
original JSW (destroying its custom loader in the process), because
I forgot to "cd" to the directory where I had made a test-copy
before I typed "jswed JETSET.TAP". If I hadn't immediately realised
my mistake, I could easily have left my JSW archive in this
corrupted state.
One solution is to mark the files I do not wish to edit as "Read
Only" (via Properties when I right-click the file in Windows
Explorer), but I'm not in the habit of doing this.
I'd rather JSWED's "Load file" main-menu option offered a checkbox
you could tick for opening a file only for reading. Then pressing F2
would give the error-message "File opened for reading only", and you
would have to use "Save file" from the main-menu if you did want to
save your changes.
Pressing F5 to run the game immediately in a Spectrum-emulator does
not work with RealSpectrum. I think the fault is with RealSpectrum
rather than with JSWED, because if I type "realspec JETSET.TAP" from
a Command Prompt, it interprets the file-path relative to the
directory in which RealSpectrum is installed, rather than the
current directory. But it would be nice if JSWED could recognise
RealSpectrum and adjust the path to compensate for this.
--------
6.1 Game
--------
Checkboxable patches are a very cool feature of JSWED, but there's
always room for extension. There are many POKEs for MM/JSW that
could be included here, and other patches such as the ones I've
written for my own games, and the ones I may write in the future.
JSWED will need to move with the times!
It would be nice if the user could customise the selection of
available patches, and add patches of their own. You could invent a
little language for this, so that the available patches are encoded
in a text-file that the user can edit without a need to recompile
JSWED, perhaps something like this:
>>>NAME= Fall any height
ENABLE= 36477,1
DISABLE= 36477,50
NAME= Infinite lives
ENABLE= 0x8C3B,0 # can recognise hex as well as denary
DISABLE= 8C3Bh,53
#The following patch is commented out
#NAME= Official Software Projects POKEs
#ENABLE= 42183,11; 56876,4; 59901,82; 60231,0
NAME= Vertical conveyors (early brick version)
ENABLE= 36271,[62,-32] # shorthand for 36271,62; 36272,-32
DISABLE= 36271,[198,223]
NAME= Jet Set Wibble
ENABLE= wibble.hex
DISABLE= unwibble.hex
NAME= Fix bug in 'fast JSW'
ENABLE= fastfix.zsm
DISABLE= unfastfix.zsm
<<<
An alternative to DISABLE would be to look up the old values from a
base file (usually, but not necessarily, the original MM/JSW). The
base files could, in fact, be the blank games of each type, that I
mentioned in my comments for Section 4.3.
Such a language would also have to encode the conditions under which
each patch is applicable* (usually unconditional, assuming that we
have separate files like the above for MM and for JSW; JSWED itself
could automatically adjust the addresses as needed for the Software
Projects edition of MM).
---
* unless JSWED automatically detects interference (even if only by
detecting that two patches want to change the byte at the same
address to two different values, which is a sound but incomplete
test for interference).
And then there's the need for relocation if two patches are encoded
to use the same memory for their subroutines or data-areas. JSWED
could keep track of free memory and allocate it automatically, or
the user could be consulted if it's a choice between sacrificing a
sprite-page or sacrificing a room, for example.
At any rate, JSWED should have a memory-map, viewable by the user,
that explains what any area of memory is used for, in terms of:
(a) address-ranges, e.g. 49024--49097 is the teleport-subroutine in
JSW:LOTR, and 49098--49102 is the teleporter-table in this
particular game;
(b) the user can ask what any individual address is used for, e.g.
49153: Screen-layout of Room 0: Row 0, Columns 4-7.
I've assumed that the user would edit the above file using a text-
editor, but JSWED could even offer a patch-editor... even maybe an
interactive assembler/disassembler!
And, of course, JSWED should allow the user to apply arbitrary POKEs
directly (as the RealSpectrum emulator does when you press F9), load
an arbitrary .hex file, an arbitrary .TAP file, or even load an
arbitrary binary file at a specified start-address (and, if the user
so wishes, up to a specified maximum length or stop-address).
6.1.1 Upgrading to 128k / Converting to JSW64
---------------------------------------------
Ideally, JSWED should be able to convert back and forth between any
two of the game-types it recognises - with the inevitable
information-loss, and with the appropriate level of interaction with
the user (e.g. if I had JSWED convert MM to JSW48, I might want to
decide what to do with each individual crumbling-floor block, or I
might just want them all converted to regular floor-blocks).
For example, if I will be halfway through writing a JSW64 game and
then decide that I picked the wrong variant, I can only see three
courses of action: (a) stick with the variant I originally chose;
(b) start over; or (c) write my own conversion-program.
I am amused by JSWED's game attempt to convert JSW:LOTR (which uses
my own player-sprite patch) to JSW64! ;-)
6.1.10 Fix bug in 'fast JSW'
----------------------------
Since JSWED offers this option, it should also offer the 'fast JSW'
patch itself (and the 'fast MM' patch for completeness).
6.1.13 No infinite death
------------------------
"No infinite death" is a misleading name, making this horrible patch
sound like a good thing! A better name would be "Safe restart
positions".
And you can't go back and disable it! JSWED should warn the user
about applying patches that it cannot undo - or better yet, be able
to undo them!
Can't JSWED "set the initial room again" automatically?
-----------
6.2 Message
-----------
JSWED should warn the user that the last character of the scrolly
will not be displayed.
----------
6.3 Memory
----------
As mentioned above, it would be nice to have a finer-grained memory-
map, and not just for 128K games.
JSWED should provide an 'undo' button here. It's all too easy to
click on something and change it without meaning to, which could
cause insidious problems if the user doesn't have the presence of
mind to change it back to what it was.
The user should be able to switch between hex and denary (by means
of a checkbox) wherever addresses are displayed in JSWED.
Why does JSWED let you allocate a guardian-class table at some
addresses but not others? Is it that the four consecutive sprite-
pages have to be free before you can do this? If so, the manual
should mention that they all have to be free.
-----------
6.4 Sprites
-----------
JSWED could learn much from JSW CK (my Jet Set Willy Construction
Kit) in this department:
The list of sprites
-------------------
It would be nice to be able to click the left or right arrow once,
and hold the mouse-button down to keep scrolling.
The end of the list should loop back to the beginning and vice versa.
It would be nice to be able to view data below 9C00 or above BFFF as
sprites (with a strong warning against editing `sprites' in memory
that is used for other purposes).
Black ink on white paper makes most sprites appear as `negatives'.
White ink on black paper would be better.
JSW CK presents the list of sprites as one sprite-page on each
screen, with Sprites 0-3 above Sprites 4-7, all nicely spaced out.
This makes it easy to see which sprites belong together -
particularly the left-facing and right-facing sprites of a
horizontal guardian.
JSW CK facilitates drawing horizontal-guardian sprites as follows:
* you can copy any sprite to the other three sprites in that half of
the sprite-page such that the sprite to the right of each sprite is
shifted two pixels to the right.
* you can copy one half of the sprite-page to the other half,
laterally inverted.
The sprite-editor
-----------------
JSW CK may not have the benefit of mouse-control, but it does
provide several facilities:
* all pixels in grid on
* all pixels in grid off
* toggle all pixels in grid
* laterally invert grid
* rotate grid left
* rotate grid right
* rotate grid down
* rotate grid up
* copy sprite to clipboard
* paste sprite from clipboard
JSWED provides some of these facilities, but through a menu rather
than a single key-press - which would be particularly useful for
JSWED's Move function (which has logical-shift semantics rather than
the rotate-semantics of what JSW CK calls "rotate" - not to be
confused with JSWED's Rotate which refers to geometric rotation).
Okay, JSWED basically provides all the above facilities, but some of
the most useful ones are confusingly tucked away under the Bitmap ->
Clipboard menu. It would be better to replace the Clipboard submenu
with the five options currently in Clipboard, which IMO are equal in
status to the other functions in Bitmap.
I also don't think we need an Exit to the main menu in the Bitmap
submenu, although the Clipboard menu should have an option to cancel
it (currently the only way is to press Esc) - if that menu is to be
retained at all.
What does the Swap function actually do? I assume it exchanges the
contents of the current sprite with the contents of the clipboard,
but it's not clear to the user.
6.4.1 Importing/Exporting
-------------------------
I'm not familiar with the +3DOS format, but why not provide a raw
binary option so that a single sprite can be saved in a 32-byte
file? That way I could exchange sprites between JSWED and
RealSpectrum (which can load and save chunks of memory as raw binary
files).
Also, when you click on "+3DOS" and then move the mouse down to
click OK, it highlights "PNG" if the mouse passes through it. It
seems that the only way to select +3DOS is to click inside the
Format menu and select it by pressing cursor-up - or to move the
mouse carefully around "PNG".
-------------------
6.5 The Room Editor
-------------------
In terms of the way the rooms are displayed, WYSIWYG is very nice in
general, but is not going to be helpful when it comes to editing
invisible rooms, or rooms with identical-looking block-types.
JSW CK draws every room using "Central Cavern" block-graphics over a
dull/bright chequered white grid, which allows the user to see
precisely what they're doing, and to count the number of characters
between gaps (JSWED could at least print the coordinates of the
current square as JSW CK does).
I submit that both these views are valuable when it comes to
editing, and the user should be able to switch between them with a
single key-press.
It would also be nice if the items had the same paper-colour as the
block they're on - usually but not necessarily Background (currently
all items are drawn with black paper).
--------------------------
6.5.1 Moving between rooms
--------------------------
Ctrl+left and Ctrl+right do not work for me. Ctrl+left moves to the
room below, and Ctrl+right moves to the room above.
< and > should wrap around between Rooms 0 and 19/63/127/255.
In JSW CK, pressing L brings up a list of rooms, while pressing J
allows you to enter a room-number.
In the list of rooms, it would be nice if you could click once on
the up/down arrow, and hold the mouse-button to keep scrolling, and
if you could use the mouse-wheel for scrolling.
In JSW CK, you can press P to return to the previous room you were
in. This is very useful when you follow a one-way exit (many of the
exits in the original JSW point to Room 0).
It would be nice to see the room-numbers of the adjacent rooms on
the screen at all times, not just when you press X. These could
easily be displayed next to the navigation-arrows in the bottom-left
corner.
Other possible extensions:
* a Find function that allows you to search the room-list by
substring (case-sensitive or not) could be useful in a game with 256
rooms;
* export the list of rooms as a text-file (like SPECSAISIE RoomsJSW):
[0] "The Off Licence"
[1] "The Bridge"
[2] "Under the MegaTree"
...
(leading and trailing spaces should be stripped or not at the option
of the user)
6.5.2 Editing exits
-------------------
I usually find it quicker to type in a room-number (à la JSW CK)
than to select the target-room from a list. JSWED should provide
both ways.
It would be nice to have a checkbox that, if ticked, sets Room T's
right-exit to S when you set Room S's left-exit to T, and so on.
6.5.3 Clipboard
---------------
When copying a room, the user might want the items copied, moved, or
left as they are.
The user might not want the exits copied.
It would be nice to be able to import and export individual rooms
(or a subset of rooms) as raw binary files, as for sprites. Or in a
special room-format that can accommodate guardian-classes, sprites
and items - each at the option of the user. Such a room-format
should be flexible enough to exchange rooms between MM, JSW and
JSW64 games.
Mirroring should transform the room to the extent that SPECSAISIE
MirrorMM and MirrorJSW do. When mirroring an individual JSW room,
the user should be asked whether to mirror the guardian-classes and
their sprites, as these affect the whole game. JSWED should provide
a function to mirror the whole game, using a mark-sweep algorithm to
ensure that each guardian-class and sprite (except any unused ones)
is mirrored exactly once. Just like SPECSAISIE MirrorJSW.
6.5.4 Room options
------------------
General
-------
When editing the room-title (or any text-field for that matter),
inserting characters in the middle should cause the rightmost
characters to flow off the right of the room-title, only actually
disappearing when you click OK and it truncates the room-title to 32
characters. The characters that are liable to be truncated should be
clearly indicated while editing - perhaps by bright red paper
(especially as the room-title text-field is 33 characters long for
the purpose of editing).
JSWED should allow special untypable characters to be entered by
allowing the user to enter their ASCII codes. And I notice that
JSWED's rendering of Room 61-63's titles isn't faithful to how they
appear in the game (JSW CK resets the most significant bit first,
then ASCII codes 0-31 appear as INVERSE 1 spaces).
Depicting which border-colour is currently selected by making it
BRIGHT is too unclear. JSW CK always sets BORDER in the editor to
the border-colour of the current room, so you can see the border-
colour all the time. JSWED could do likewise by changing the dull
white space in the Room Editor to the current room's border-colour
(changing the black text at the bottom of the window to white when
the border is black, blue, red or magenta).
Whenever I write a MM/JSW room, I consider it important to remember
to set the border-colour, and I try each border-colour until I find
the one that feels most suitable. Other JSW authors like to cluster
rooms together by giving them the same border-colour.
Shapes/Colours
--------------
I would really like to see these two menu-options integrated into
one, as it makes little sense to select the colour-attributes of a
block-graphic without being able to see its shape.
There seems to be a bug in Shapes whereby trailing lines appear
below the shapes with no apparent logic.
Depicting which ink/paper-colour is currently selected by making it
BRIGHT is too unclear. JSWED should show the coloured shape like JSW
CK.
JSWED should warn the user about occurrences of the Block Graphics
Bug (for game-engines in which it is not fixed).
JSWED should warn the user when two block-types have the same colour-
attribute, and describe the effect this will have (e.g. escalator,
springy platform).
JSWED should warn the user when the background and static nasty
block-types (i.e. Air and Fire) are equal in PAPER, BRIGHT and
FLASH, with INK 7 (white) for static nasty, because this causes
background blocks to kill Willy when he colour-collides with them.
6.5.5 Guardians
---------------
It would be nice to have a closer integration between the
functionalities described in Sections 6.5.5 and 6.5.7, as the menu
for adding, editing and deleting guardian-instances feels divorced
from the guardian-instance list as it appears in the Room Editor. I
believe JSW CK achieves a closer integration.
6.5.6 Conveyor options
----------------------
It's confusing to present this in the manual before "Cell editors"
(Section 6.5.8). I suggest moving "Cell editors" to Section 6.5.2
(after "Moving between rooms" and before "Editing exits".
The "Ramp Left" and "Ramp Right" options are also confusing, as they
appear to remove the conveyor, and don't change the direction of the
ramp if the user selects "Ramp Left" when there's already a '/' ramp
in the room and vice versa. And the lay user may be unaware that the
colour-attribute of Conveyor has been altered.
My suggestion is to axe the "Conveyor options" menu altogether. Let
the user learn how to make a conveyor-ramp by giving Conveyor and
Ramp the same colour-attribute, and find a better way to edit the
direction of a conveyor, treating left, right, off and sticky as
equal in status.
The manual's description of a sticky conveyor as "stationary" leaves
much to be desired.
6.5.7 Guardian / guardian start frame
-------------------------------------
JSWED and its manual should use the term "guardian-instance" in this
context, to avoid possible confusion with editing guardian-classes.
I can't see the logic in how "ALT+numbers" changes the start-sprite,
and it took me a while to figure out that you can change it by
clicking the sprite in the guardian-instance list rather than the
sprites at the bottom of the window.
Does ALT+1 have the same effect as clicking the sprite in the
guardian-instance list? Does ALT+(any other number) have any effect
at all?
The lay user is going to be completely baffled by what it means to
edit the start-sprite, considering the confusion that even I've just
had to work through. I believe JSW CK's way of editing the start-
sprite is much clearer.
This section would be better presented before "Guardians" in the
manual. In other words, the subsections of Section 6.5 would be
better ordered and titled as follows:
6.5.1 Moving between rooms
6.5.2 Cell editors
6.5.3 Editing exits
6.5.4 Clipboard
6.5.5 Room options
6.5.6 Guardian-instances (was "Guardian / guardian start frame")
6.5.7 Adding, editing and deleting guardian-instances
(was "Guardians")
6.5.8 Cell editors
------------------
I like a lot of symmetry in my rooms, so it would be cool to have a
`symmetry-mode' of editing the screen-layout (enabled by ticking a
checkbox), where placing a block at (y,x) also places a block of
that type at (y, 31-x).
Ramps and conveyors
-------------------
JSWED should allow you to grow a ramp or conveyor off the vertical
edges of the screen (but should not allow you to grow a ramp off the
top of the screen). I like to exploit wraparound ramps and conveyors
in my games, so of all my suggestions, this should be one of the
highest priorities.
JSWED should allow you to get hold of the existing ramp or conveyor
in a room, and allow you to grow or shrink it, or change its
direction. So I suggest that pressing C or R should grab the
existing ramp or conveyor, with another key to toggle its direction
(including off and sticky for conveyors). The direction of a
conveyor should not be determined by whether you grow it to the left
or right.
Advanced users who wish to work with 'invalid' ramps should be
allowed to enter the direction of the ramp as a denary byte-value;
grabbing an existing ramp should preserve this value, and the least
significant bit of the direction determines whether it's a '\'
or '/' ramp.
Items
-----
JSWED's item-editor is grossly oversimplified, not allowing you to
place two or more items at the same coordinates (as in "The Beach").
This is a great shame, as I love the sound of collecting multiple
items at once.
JSW CK allows you to select individual items from the global item-
table, and position them where you will. It even allows you to move
an item to another room, preserving its position in the item-table
for those of us who care about such things.
I would very much like to see JSWED offer a way of grabbing hold of
an existing item and repositioning it even over another item - or at
least some way of adding items on top of existing items in the same
character-square - as the highest priority of all my suggestions.
(to be continued from Section 6.6)
--
Dr. Andrew Broad
http://www.geocities.com/andrewbroad/
http://www.geocities.com/andrewbroad/spectrum/
http://www.geocities.com/andrewbroad/spectrum/willy/
|
|
|