Re: User Interface Design

Alfie [UK] wrote:

There are game object owner flags, but they are not enforced at the
moment. It's a community sand box.

I'm thinking of some of the mini-maxers in my group, they like to be
able to sneak a peek at the enemy to work out who's the softest target
:)

Right now, a player's marking on the data card are private. So, anyone
could look at the undamaged stats on a unit, but they would not have
the ability to see which components are damaged, how much fuel or ammo
remains, etc.

It's probably a sad indictment of our group but we hardly ever play
without a GamesMaster/RulesMaster to keep an eye on cheating and act as
arbiter in disputes, hence me saying it would be nice if the GM could
control what info is and is not visible.

I'll see what I can figure out on that. Since VirMin is rules
agnostic, there are some limitations and assumptions that have to be
kept.

Interesting. Coming from the wargamer/hex grid camp, I missed the
sublty of that game play. I'll have to see what I can do about it.
Good idea on the set and place mechanic.

I think 'place ends your move' comes from Chess, i.e. when you release
the piece that is considered to be your move. For games where the moves
aren't pre-plotted we use an initial position marker to indicate a
possible move, and once the move is confirmed the marker is removed.

'Place and orient' is a common feature in computer wargames, and it
seems to work well as an intuitive mechanism for non-computer gamers as
well.

Noted.

I'm not sure how many table-top games also support 3D visualisation, we
did try something with Full Thrust in 3D Cinematic mode, and I'm not
sure how you'd handle some of that in your interface, probably mouse +
modifier keys a la Homeworld or similar.

That's what I had in mind. With a little practice, the Homeworld
system becomes second nature. Right now, I have height bars that are
used to indicate units that are above or below the map plane.

Similarly, horizontal and vertical scales are in the game script, but
not implemented as either a 2D or 3D ruler.

Might be our mini-maxers again but it's often useful to just take a
straight line measurement between groups or objects, we found when we
banned pre-measurement estimation of moves and firing arcs that it led
to more frustration for those that couldn't visualise the distances.

Do you have fire-arc/range overlays as well ?

They're on the to-do list. Right now, you could add them as slave
models to the main model, but I want them to be toggle-able. So, I
have some custom coding that I want to add for that feature. I also
want to make sure translucent spheres and cylinders are available as
on-the-fly models for blast radius and weapon/sensor range purposes.

Well, the program is what I'd call an alpha (functional, but not pretty
with some to-do items remaining.) Are you interested in seeing it as a
beta (after UI reform) or in its current condition?

I'd be interested to be a beta tester, I can probably rope in a few
friends to give it a go for both something like Full Thrust and as a
battle tool for AD&D or Call of Cthulhu (where we usually end up using
dice or coins to visualise relative positions cos someone forgot the
miniatures :) ).

I welcome the opportunity and I'll keep your name and e-mail address
handy for when VirMin goes beta. Funny that you should mention AD&D.
One of my to-do list items is to create a generic dungeon hack game set
and write a small utility to create random dungeon levels with numbered
encounter tokens.

One idea that popped up might be to drop the right-click functionality
and replace it with a context sensitive right click menu ala Windows.
I had originally tasked the right mouse button with camera control and
the arrow keys with movement. If I added in drag and drop movement,
that would free up the keys for camera control, and the right button
for the menu. Thoughts?

No reason not to use both, just use modifier keys to control which
functionality is affected. For instance the mouse can control the camera
orientation and arrow keys it's movement, but when ALT or CTRL is
pressed the mouse controls the orientation of the currently selected
piece and arrow keys move it.

Programming wise, it would be a lot easier to standardize on one or the
other. The program is being written in Dark Basic Pro rather than
something like VB. So, I have to write code for all the methods that
get supported in-game rather than relying on Windows events and default
behaviors.

You'd need to work out what is the more common action, movement of a
peice or camera (I would think camera in this instance) and therefore
what needs to be the natural functionality, and what should be a
modifier.

Aye. One of the default behaviors is auto-focus on the selected object
which also allows zooming and orbitting the camera around that selected
model. So, object selection has some inherent camera control without
using any other keys or mouse actions.

Right-click menus are definitely a good idea as most Windows users will
be used to using them. One thing I learnt with UI is wherever possible
borrow from existing control methods that your target audience will be
familiar with :)

I think I'll run with that idea. In theory, I can add attributes to a
given object and that would allow for a context sensitive right click
menu based on ownership, game role, and object type.
--
TAZ

.