Resource centre for ZX Spectrum games
      using Manic Miner and Jet Set Willy game engines

 

 

Previous message		Next message

 

 

Message: 5074

Author: Daniel

Date: 17/11/2005

Subject: JSWED - Daniel's suggestions

 

First of all, thank you, John, for answering my recent question about
resaving files.

It is great that the work on JSWED is continuing and that we have
welcomed the release of version 2.2.5 :-) . Today I would like to
offer some comments about and postulates for JSWED. I am going to
talk about things which can, IMO, be improved, but before I start, I
want to say again to John: Thank you so much for this great tool
which has given me so much joy so far!!! (and deprived me of my much-
needed sleep over so many nights :-) ). Does this humble opinion of
mine (certainly shared by a lot of the other MM/JSW fans) sound like
enough motivation for you to start work on JSWED 2.3.0 again? :-)

I appreciate very much Andrew's comments about JSWED, and other
people's comments as well. I generally agree with most of Andrew's
comments, at least the ones I am able to evaluate – since I have
never worked on a Manic Miner or JSW64 game, I have nothing to say in
this field.

I believe there are two areas of possible improvements to JSWED: one
which concerns things that JSWED cannot do at this point – and these
should be the priority, IMO, if John kindly keeps developing this
great tool – and the other – making JSWED easier to use, which would
be great but is not equally urgent, because, as Sendy said, "as a
regular JSWED user I find some of areas where JSWED is not as
conveniently set-up as it could be become a non-issue in the end,
because you just get used to working with it".

So here is my list of priorities for the improvement of the otherwise
excellent tool which JSWED is, and some other comments. I put the
suggestions more or less in order of importance to me:



I. Things JSWED cannot do at this point


1. The ability to insert arbitrary POKEs.


2. The ability to place two or more items at the same coordinates.

Andrew has mentioned it and I absolutely agree it is important.


3. The ability to do things with the tunes

Eventually, it would be very good to have a music editor, as Igor
mentioned. However, the first "minimal" step should be – IMO – to be
able to import (and export) the tunes – just like you can do with the
screen or the sprites – so that one can use other people's tunes
(with their kind permission of course) if one is unable to create
one's own. This concerns both the title tune and the in-game tune, of
course, in all game engines. The next step would be a music editor,
but that's a much more advanced task, I imagine.


4. The ability to edit the colour attributes of Maria, the toilet,
the foot and the player on the Game Over screen, and the barrel on
the Game Over screen, as mentioned by Andrew.


5. The ability to export lists of room names – as described by Andrew.


6. The ability to clearly edit arrows.

Andrew wrote:

> 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.

This would be very useful.


7. A description in case an arrow is invalid – as Andrew said, to
identify the type of invalidity and indicate its effect.



II. Bugs and problems

1. It would be very good to definitively eliminate (if possible) the
problem with the program crashing (disappearing) while selecting
sprites for a guardian. It would be great to have this eliminated,
because it would save the authors the necessity to save the game
almost every time before choosing the sprites.


2. Andrew wrote:

> 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").

It seems to me that ALL vertical guardians go down initially – isn't
that right? Which is a great shame, because it would be great to be
able to set a guardian to go up first. So if it's a bug, it should be
corrected so that guardians can be effectively set to go up
initially. And if this cannot be done, then this field should be
eliminated for vertical guardians, because it's misleading.



III. Things that have to do with the "elegance" of created files.


1. Andrew wrote:

> I don't like the way JSWED imposes its own BASIC loader and
> Spectrum- filenames when resaving a TAP file. This is okay when
> saving a game that was loaded from a snapshot (…)

It's not necessarily okay. If you load a snapshot of a Manic Miner
game and then save it as a .tap file, JSWED gives the name
Program: "JetSet" and then Bytes: "jsw.js2". It would be nice (for
the sake of elegance, if nothing else) if JSWED made a distinction at
the moment of saving the game and gave appropriate names to every
kind of game it handles.

I agree with Andrew's various postulates as far as resaving .tap
files is concerned.



IV. Improving JSWED's user-friendliness


1. The ability to go back to the previous room.

Andrew mentioned this, saying: "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)".

I think this would be an extremely useful function, and not only for
one-way exits.


2. - Making JSWED show updated/modified characters in the room names
- A quicker update of the character-set display

When you modify the characters in the font editor, and then edit the
rooms, in the room names you still see the standard characters, not
the modified ones. This makes one's work very difficult if one is
using a number of modified characters (i.e. diacritical characters
for various languages), because one has to remember which standard
(unmodified) character stands for which modified character.

There is also a related request:

Andrew wrote:

> The Font Editor doesn't update its display of the character-set as
> (or even after) you edit each character.

It does update it when you leave the font editor, exit the game (to
the main screen) and then go back to the font editor – then the
edited characters are displayed properly in the character-set. But it
would be nice if they were displayed properly right after editing (or
even while editing, but that's not really necessary, I think).


3. The ability to move quickly around the scrolling message.

Andrew wrote:

> It would be nice if, when editing text-fields, the cursor could be
> positioned by clicking the mouse.

Also, while editing the scrolling message (especially in JSW128 and
probably JSW64), it would be very nice to be able to move around
rapidly using the "PageUp" and "PageDown" keys (or other keys), like
you can do with the sprites. If the message is very long and one
needs to change something i.e. at the beginning, it takes a long time
to get there.


4. An easier and more obvious way of placing diagonal guardians.

I agree with Igor's and Sendy's comments that placing diagonal
guardians leaves much to be desired. I have always been able to place
the diagonal guardians the way I wanted them to go, but at times it
took me a long time and the effort seemed very frustrating until I
got it right.



V. Some points in Andrew's comments which caught my particular
attention because I very definitely agree with them.

1. Andrew wrote:

> 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.

Absolutely!


2. Andrew wrote about 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.

Absolutely!


3. Andrew wrote:

> 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).

Absolutely!


4. Andrew wrote:

> 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.

Absolutely!


5. Andrew wrote:

> (…) 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.

Absolutely! And then one should be able to undo this action.


6. Andrew wrote:

> 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.

Absolutely!


7. Andrew wrote:

> 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.

Absolutely!



VI. Some points where I do not agree with Andrew or have some
alternative comments:

1. Andrew wrote:

> 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.

This is one point where I don't agree with Andrew in the sense that I
think it's quite clear what the Swap function does. I have used it a
lot, both for the sprites and for the cell patterns, and I think
it's one of the most useful and vital, say: basic, functions in JSWED.


2. Andrew wrote:

> There seems to be a bug in Shapes whereby trailing lines appear
> below the shapes with no apparent logic.

I'm not really sure what Andrew means, since in my experience the
lines which appear below the shapes have always clearly corresponded
to the shapes in the grids above.


3. Andrew wrote:

> 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.

It does. It says in chapter 6.3 ("Memory"): "note that to allocate a
guardian table you will need four consecutive memory pages (eight for
upgraded Softricks games)".


4. Andrew wrote:

> 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 (…)

This and what follows in Andrew's message seem an important
suggestion. I would just like to ask John not to eliminate the
checkboxable patches. If you manage to extend the possibilities
offered by JSWED along Andrew's suggestions – this would be great,
but please, just leave the possibility to apply the basic patches
just by checking a box, for people (like myself) who may not be able
to do any more advanced editing (simple as it may be). Perhaps Andrew
didn't suggest eliminating the checkboxes at all, I'm not sure about
it, but I'm writing this just in case: I think the most perfect thing
would be to still have the checkboxable patches as they are now (or
more of them, but in the same form) for "simple" users, and all the
editing abilities described by Andrew for "advanced" users.


Finally, a question to the knowledgeable among you: what does WYSIWYG
mean exactly?


Daniel

 

 

	Back to the Yahoo! Archive
Previous message	home page	Next message