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: 5010
Author: andrewbroad
Date: 04/11/2005
Subject: JSWED: Andrew's comments (Chapters 11, 12, 13)
(continued from Message 4989)
#####################
Part III: JSW64 games
#####################
"Part III" should appear at the top of p.22 rather than the bottom
of p.21.
===========
Terminology
===========
The meaning of the term "cell-type" needs to be ironed out, as
sometimes it is used to refer to the defined block-types in a room,
and other times to refer to the behaviour of a block-type - which is
fixed in non-JSW64 games, but can vary in JSW64.
So we need two distinct terms here, and I suggest the following:
* CELL-CLASS: a class of cells which the room defines to have a
certain colour-attribute, pixel-pattern and behaviour;
* CELL-TYPE: the behaviour associated with each cell-class, i.e.
whether it's Air, Water, Earth, Fire, Ramp /, Ramp \, Conveyor >,
Conveyor < or Trampoline;
(Item, Solar and Custom are not cell-types, since they can't be
associated with a cell-class.)
So the "cell types" in Section 11.1 are "cell-classes" by the above
terminology, while the "cell types" in Section 13.1.1 are indeed
cell-types.
And a third term would allow us to avoid the ambiguity of saying
"cell" on its own:
* CELL-INSTANCE: a particular cell in a screen-layout, which must be
of a certain cell-type (except in Variant Z and Manic Miner, which
allow disassociated colour-attributes).
I have chosen these terms for cells by analogy with my terminology
for guardians in JSW48 and JSW128:
* GUARDIAN-INSTANCE: a particular guardian in a room;
* GUARDIAN-CLASS: an entry in a JSW guardian-class table;
* GUARDIAN-TYPE: Horizontal, Vertical, Arrow or Rope.
So every particular object is an INSTANCE of a CLASS, and every
CLASS is of a certain TYPE which defines its behaviour (some
computer-scientists consider the terms "class" and "type" to be
synonymous; I use "class" in the sense of "a type which is defined
as data", and "type" in the sense of "a type which is hardwired into
the game-engine as code rather than data").
I think this is an elegant solution, though we'd have to be careful
every time we write "type" that we don't actually mean "class" - and
I'm so used to calling cell-classes "block-types" by now, since MM,
JSW48 and JSW128 make no distinction between "cell-class" and "cell-
type".
=================
11 JSW64 Overview
=================
I would really like to see semi-automatic conversions between the
different variants of JSW64. The uninitiated author could easily
make the wrong choice due to an imprecise understanding of the
differences (as in the table in Section 11.1), or not yet knowing
the technical requirements of the game (s)he's setting out to write.
JSWED should be able to convert rooms from one variant to another
(and back to MM, JSW48 or JSW128) to the most faithful extent
possible, with a clear indication to the user of what is lost from
each particular room converted, and interaction with the user to
make important decisions.
e.g. "Should this Crumbly block be converted to Water or to Air?"
The user should be able to make this decision for the individual
block, for all Crumbly blocks in the room at once, or even for all
Crumbly blocks in the whole game at once.
It's cool how you can convert any MM game to JSW64 by substituting
for MANICMIN.SNA in the JSW64 installer. JSWED should easily be able
to do at least this, although when I tried it on MM:N-AT (which uses
the "Specials by room" patch), it seemed to get the HG and VG
sprites mixed up (I noticed this in "Dr. Karl Kennedy's Surgery",
Variant V).
On the Game screen, what is "Diagonal guards bug", and why would one
want to introduce this bug?
-------------
11.1 Variants
-------------
There are discrepancies between the table in the manual and the one
at http://www.seasip.demon.co.uk/Jsw/jsw64room.html
Variant X has 606 free bytes per room according to jsw64room.html,
but 576 according to the manual.
The asterisks (for "Block types") and parentheses (for "Guardians
per room") in jsw64room.html should be transferred to the manual,
with a consistent decision as to whether Variant Z has 13 cell-
classes (in the "real" sense) or 256 (in the sense of arbitrary
colour-attributes - not "cell-classes" by my definition of the term).
=============
12 Memory Map
=============
What's the difference between "R" and "r"?
========
13 Rooms
========
I found a nasty bug when I cleared "The Bathroom", pressed Undo, and
it wrote "The Final Barrier" (the previous room I had visited) into
Room 33! I guess JSWED hadn't set the Undo-point when I moved
to "The Bathroom" in whichever way I did move.
----------
13.1 Cells
----------
For a consistent user-interface, I suggest that the 48K MM & JSW
editors use keys 0-7 to select a cell-class, rather than A,W,E,F,
&c. MMSE and JSW CK use numbers rather than letters (the difference
being that each keypress places a cell-instance of that cell-class,
rather than merely selecting a cell-class for another key to place).
Hex-digits are convenient for the variants with more than ten cell-
classes, are not they? :-) Let's hope the user doesn't get too
confused over A, E and F! ;-)
When you change a cell-class's Type in the "Room graphics" window,
the cell-type displayed at the top left of this window should be
updated immediately; it might also be helpful to show the cell-class
in hexadecimal (e.g. "(F) Water") for consistency with the screen-
layout editor.
JSWED should warn the user about changing a cell-class's Type in
variants where the cell-type of each cell-class is set up globally.
With great power comes great danger.
13.1.1 Extra cell types
-----------------------
Items
-----
I take it items are stored by room rather than in a global item-
table?
How does the author track down mislaid items?
How does the game keep track of how many are needed to remove Maria?
How does the game-engine keep track of which items have been
collected?
Solar
-----
I can't seem to place a solar `cell' - I click and no orange sun
appears. And in "Solar Power Generator", I can move the sun around,
but how do you get rid of it?
I later learned that you get rid of solar power by setting its
colour-attribute to 0, and introduce it by setting its colour-
attribute to non-zero - surely there should be a more obvious way,
such as a checkbox that toggles the colour-attribute between 0 and
bright white ink on yellow paper (with a clear indication to the
user that this colour-attribute has been altered).
Custom
------
The manual should mention that if you happen to set a colour-
attribute already associated with a cell-class, then it will behave
as the cell-type associated with that cell-class, rather than as
Water.
I'm not sure about JSW64's policy of using the Cell-Class 1 pixel-
pattern for disassociated colour-attributes. Manic Miner uses
seemingly random pixel-patterns - my guess is that it runs through
memory (even after the cell-class definitions) looking for the first
occurrence of the colour-attribute, and using the next 8 bytes as
the pixel-pattern.
Seeing as Variant Z represents screen-layouts with arbitrary colour-
attributes, why not allow the room's 256 free bytes to be used as an
overflow-buffer where extra sets of colour-attributes and pixel-
patterns can be stored if the author so wishes? If the game-engine
didn't find the colour-attribute in the cell-class definitions, it
would resume searching for it in the free bytes.
--------------------
13.2 Room properties
--------------------
You get to this by selecting "Room options" from the right-click
menu, or by clicking "O:Options", and then clicking "General" -
JSWED should stick consistently to either "options" or "properties",
and in general, the name at the top of each menu should always match
the name you clicked to get to that menu.
Air
---
Representing the lack of an air-limit by the value 162 is rather
inelegant. It should be checkboxable instead (with the "Air" value
only appearing to the user if the checkbox is ticked).
No Kamikaze
-----------
An interesting name for what I would term "item-retention" if I
could afford a wider window. ;-)
"A sadistic game designer", eh? :->
Bonus Room
----------
Did I read somewhere that the items in a Bonus Room don't count
towards removing Maria? Sacrilege!
It's really cool that the screen colour-cycles when you get an extra
life, as in Manic Miner.
Perhaps certain JSW games could give you an extra life after you've
collected a certain number of items, or exceeded a certain score (to
which points are awarded for collecting items and visiting rooms
that you haven't visited before).
There's a bug (or useful quirky feature?) whereby erroneous colour-
attributes appear in the playing-area if you acquire too many lives.
These colour-attributes behave as Water unless associated with a
cell-class (but unlike Custom cells, they don't cause the
Cell-Class 1 pixel-pattern to appear).
Escalator
---------
What happened to being able to combine the behaviour of cell-types
by giving cell-classes the same colour-attribute?
You can't make an escalator (ramp+conveyor) that way in JSW64, which
presumably means we'd lose the ramp-walls in We Pretty, the conveyor-
walls in JSW:LOTR and the springy platforms in JSW (again) if we
converted these games to JSW64?
And I was sooo disappointed not to be able to make a crumbling ramp!
Land softly
-----------
The editor calls this "Land safely".
It's pretty cool that this feature can now be room-specific, along
with the superjump and the player's sprite. It would be quite
artistic to have a game with up to four characters, each with a
different combination of superjump and fall-without-dying.
---------------------------
13.3 Room-specific graphics
---------------------------
Import/Export would be extremely useful here.
It would also be nice to be able to see these sprites in the Sprites
section, although I appreciate the headache this would cause with
extending the representation of memory-addresses to cover the extra
banks in a 128K Spectrum (I face this headache myself if I wish to
extend SPECSAISIE's memory-model to 128K, enabling me to write such
functions as ItemsJSW128 and RoomReachJSW128).
-----------------------
13.4 Conveyor animation
-----------------------
It's interesting to see how JSW64 extends the field of conveyor-
mechanics:
* If you have two conveyors trying to pull Willy in opposite
directions, the one under his right character-column takes
precedence.
* You can animate a conveyor in the opposite direction to its
behaviour!
------------------
13.5 Final Barrier
------------------
If a room uses this feature, then the graphical buffers should be
displayed WYSIWYG while editing the screen-layout.
--
Dr. Andrew Broad
http://www.geocities.com/andrewbroad/
http://www.geocities.com/andrewbroad/spectrum/
http://www.geocities.com/andrewbroad/spectrum/willy/
|
|
|