adonthell-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-general] GUI design


From: Andrew Phillips
Subject: Re: [Adonthell-general] GUI design
Date: Fri, 29 Jun 2007 11:59:35 -0500



On 6/28/07, Kai Sterker <address@hidden > wrote:
On 6/28/07, Andrew Phillips <address@hidden> wrote:

Guess we're still in the brainstorming phase ... so my question to
everyone is what kind of information should be visible while in 'map
mode'? (my opinion in brackets)
Not sure if the portrait should even be there. Would you really want
to look at your character's face all the time? Also, what happens if
there is a party or companions? More portraits? Or just always show
the active/player controlled character?

* basic stats like health and power [yes, at least while in combat]
* character portrait [maybe not always, just only during dialogue]
* effect icons [maybe have one global icon that appears when character
is diseased, cursed, etc. and a special stat page with the details]

I'll address these three first, since they seem logically grouped to me. I wouldn't mind seeing the character "portrait" all the time. I say "portrait" because it might be just as acceptable (an image is an image, after all) to put abstract symbols - weapons, runes, race/organization sigils - in place of the actual character portrait.

In the case of companions, summoned things, etc, I think we should show smaller portraits, or find some way of displaying their status. Ultimately, that's the important thing to me: being able to quickly see character status. A full character portrait isn't absolutely necessary, but I'd like to be able to glance at my screen and be able to judge my chances of surviving the next fight without healing or resting to recover power. If that information is in a sub-screen, flipping back and forth repeatedly is likely to become annoying rather quickly. If it's an option I can toggle someplace, I'd probably keep it on all the time, or almost all the time. For "safe zones", if we have them, it might be nice to toggle the status indicator off, so that the portrait doesn't get between me and NPCs I might want to locate, but if there's any chance at all that I'll be accosted by something, I'd want the indicator to come on again.

Wait, there's an idea. Might we auto-activate the indicator (if it exists) whenever the game goes into a combat mode?

* 'hot key items' [probably yes, see below]
* icons to access options/inventory/stats/etc [no, don't use mouse much, have keys assigned that bring those up instead]
* equipped weapon [possibly, with option to toggle between weapons on the fly]

I think the Options, Inventory, Stats, etc can in fact be key-based, as long as the user documentation highlights them sufficiently. If we want to include icons at all, they can be very, very small and still be effective. We might need them, however. As an artist friend of mine once told said, we're programmers, so we use the keyboard for everything. My wife, who is new to cRPGs, it still learning to do things by hot-key. I suppose that aspect of design might come down to guessing the users' most likely expectations and then meeting them.

* mini map [no, should be separate if available at all]

A good in-screen mini-map would seem rely heavily on transparency and having a lot of screen real estate.  Also, I'm not quite sure that there would be any difference between the mini-map and the main map, at least for DB. For Adonthell 1.0, a mini-map might be really, really useful, at least in maze-like areas like towns or cities. I'd hate to try to navigate large urban areas like Elgilad, Cirdanth, or heaven help us, the Mines of Zhet'kal, without one.

There might be some threads in the ML archive that might apply too,
but I am not sure if it is worth digging them out. Might as well start
a fresh design ...

Sounds good to me.

> We've already raised the question of how many usable 'item' slots we need. I
> don't think I have an immediate opinion on this, except that I think Kai is
> right to say that two is too few.

One idea passed around was to still have a limited number of slots,
but allow to queue several items/spells/feats. One key (or button)
would then be used to activate the current item, another one to toggle
between queued items. However, that approach requires more management
ahead of time, interrupting gameplay.

An alternative might be to have one slot for magic, usable items and
fighting feats. Two keys/buttons are required to cast the spell/use
the item while the feat is always on. Then 3 more keys to switch
quickly between 'items' of the same category.

You've lost me on that specific idea. 

That way, you don't have to bring up the inventory all that often. In addition, you could make
toggling more 'intelligent' by

* sorting items by number of times they have been used (so you'll get
faster to your favorite spells and feats)
* filtering duplicate items (so you don't have to cycle through ten
healing potions before reaching the next item)

I like the idea of grouping items, at least in terms of potions, scrolls, and the like. The grouping would make some of these items pseudo-stackable, wouldn't it?

We might also have a slot for weapons, similar to fighting feats. As
for key mapping, something like 1 - 4 to toggle each 'item' and more
special keys for casting spells, using items and attacking with the
active weapon/feat combination.

I think we should have a weapon slot visible, though how we would denote separate weapon sets and allow characters to toggle between them might be more difficult (and impinge on the inventory system). Just to throw out main cases on this without delving deeply into it, I think there are five basic states of being armed:

1) having nothing in either hand
2) having a one-handed melee weapon in one hand and a non-weapon item in the other. Most likely, a shield or a light source.
3) having a small ranged weapon and a non-weapon item
4) having a large melee weapon requiring both hands
5) having a large ranged weapon requiring both hands

Andrew

reply via email to

[Prev in Thread] Current Thread [Next in Thread]