Re: 3.0.9 - shop UI changes are for the worse.

Nick <nckmccnnll@xxxxxxxxxxxx> writes:

On 2008-02-15 01:24:15, Eddie Grove <eddiegrove@xxxxxxxxxxx> wrote:

Nick writes:

So you could

3. Get the player to choose action and then what to apply it to (verb, noun).
This is the old system, and probably the best because it is straightforward, and
everyone is used to it already. Because of the limited range of commands, it's
also a case where the verb, noun syntax works fine for pointer commands.

This is a time of flux. You might as well try to do things right,
rather than reverting for the sake of reverting.

I've given this a little thought, emphasis on "little". :)

I think the right approach is to consider items in the store to be analogous
to items dropped in a square on the ground.

Any command you could give followed by a '-' to select from the floor should
be usable in the shop in the same way, unless it is disabled. Casting a spell
from a book could be disabled, but browsing it would not be.

You would want a table listing for each command whether it is enabled, and
whether it acts on your inventory or on the "floor", meaning items in the
shop. Then you toss in a side effect that items dropped or picked up in a
store other than the home change the gold counter, and you are almost done.
You want [virtually] to force "prompt-on-pickup" to be true, and you need to
add my extra "buy-out-the-store" command, just because. :)

I think the way to do this is to add a 'K' command that destroys all of the
items in a floor space, and that obviously generalizes to what I want in shops.
I'm moving squelching back into 'k' [obviously other keys for rogulike keyset].

On second thought, there should be a global table listing all commands, and
those should be some of the fields in it.

I think this model is sufficient, and clean, and fairly easily implementable.

OK, having given it a little thought myself, I'm inclined to disagree slightly
for a couple of reasons.

The philosophical reason: buying from a shop is too different from picking up
stuff off the ground. You are safe from attack in a shop. It's the only use
for money in the game, so gold changing hands is more than a side effect, it's
the point of going in there. As such, it deserves its own interface.

I wanted to add a command letter to buy out a store. After more than an hour,
I couldn't get it to work. I gave up and overwrote the '?' for the help
command. Stuff is in too many places.

Multiple interfaces are bad. Context-sensitive displays are good.
Perhaps I am splitting hairs so fine I'm not making any sense.

Gold changing hands really is just a side effect!
The game would not be so different if stores gave away their stuff for free.

The practical reason: suppose you amalgamate the buying code with the regular
item selection code (which did appeal to me at first). Either the item display
will change based on what items are valid for that command (which seems likely
to lead to the sort of player confusion that we're seeing with the new
interface); or there has to be special treatment of the shop case, in which case
you might as well
just have a different interface anyway.

The solution is to change the item selection code. There is no reason that
the floor items need to be relabeled so that the first target is (a).
Everything can be consistent and still work fine in shops. When I select from
my pack, the items are not relabeled, so there is no point in relabeling them
when selected from the floor. For macros that want the top object, we can say
that after the initial '-', a successive '1' or '=' [just don't use '-' or a
letter] selects the first viable target object on the floor.

There are only two commands in V that involve money in a store: dropping, and
picking up [and my new "destroy everything" command]. None of the other
commands involve money, such as wielding or browsing or item destruction or
inspecting etc. It is bad coding practice to have copied code to deal with
everything, even tiny bits of copied code, just because you have some aversion
to putting money handling into the drop/pickup code.

I forgot that games with quests and store services really need to reuse
command chars in the shops. I should have allowed for that in the table I
described originally. That allows Timo to keep using p to purchase.
I really hate this, but it seems necessary for variants.

Another thing I missed is the special handling necessary when picking up the
last item in a non-home store, but it's no big deal to add one more test and
function call to the end of pickup code dealing with store context.

A bonus to my approach is that it will generalize nicely to adding other
contexts. E.g., perhaps you could add dungeon temples, where 'p' for pray
would have a different meaning but most other commands remain unchanged or
disabled. That's a major endeavor with the current architecture, but trivial
with my proposal.


Relevant Pages

  • Re: How do you store your stock?
    ... --As the saying goes no shop is big enough. ... I made a point to store ... as much stuff as possible off the floor so I got good at making bar racks ...
  • Re: Really dumb IPL question
    ... In my experience some customers will balk if as vendors we just say "take ... "put a start command wherever your shop puts start commands" I would prefer ... Would a $VS command in the JESx init deck be a good place to put a start ... command for something that probably wants to come up after JES2 and TCP/IP? ...
  • Re: PKZip25 - How to include the current folder to the files ?
    ... I use -dir=full and list files, as in this example, but it should work ... PKZIP Command Line Translation Table ... store directory path names during compression, ...
  • Re: link new field command button to contacts
    ... The ContactItem object has only one place to store such links -- in the Links collection. ... Author of Configuring Microsoft Outlook 2003 ... the same contact in all of the command button fields that I have set up. ... those automatically to my calender so it sets up a reminder? ...
  • Re: Return results from a parameter query using a custom form back into the original form....
    ... I have 3 parameter queries that run off command buttons. ... user to enter a shop name. ... "These 3 buttons run off of a parameter query." ...