Re: User Interface Design

On 24 Mar 2006 09:17:04 -0800, "zircher" <tzircher@xxxxxxxxx> wrote:
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.

That's fairly usual with table top, you should be able to see the basic
unit config just by seeing the model, 'oh they put down orc grenadiers,
so I know they have so and so stats', I think the next step is where
most projects break down (mine included) but in some games it is
necessary to hide certain info, Full Thrust (I keep using it as an
example but it's how I found you) has optional sensor rules so you only
know the class of a ship (which hints at it's size) from a visual scan,
and you don't get more detailed info without using an active scan.

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

If you're going to keep it purely sandbox, all parties in, then don't
worry about it. If you want to try to cater for moderated games then
allow every single piece of data you display openly to be configurable,
but allow the GM to save sets of data so that a GM can moderate
different types of game just by loading a settings file.

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.

It has to be the quickest to pick up third-person 3D system going, I've
not seen better.

A minor trick is to offset the model a small percentage up the height
bar. If you're allowing 3D rotational viewing then when the view is
shifted to look down from above, the positions look close to a 2D flat
plane, but players get a sense of another object being above or below
them by looking along the level plane.

I'm not sure that it would fit very well with the other types of games
you want to support though, so make it optional.

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.

Oh, has to be on a toggle, users like to think they control such things
:) You might also want to code it so that objects in and out of the fire
arc/range are highlighted differently. There is something kind of
strange yet pleasing in moving your ship then checking your fire range
and seeing your proposed target light up like a christmas tree :)

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.

Well, the email address I use in USENET is a spam trap(and not even
mine), so if you want to get in touch please use 'cgdd at delphia dot co
dot uk' replace 'at' with @ and 'dot' with . as appropriate. I'd be
happy to keep in touch about your developments and any testing that I
can do for you.

I have several unfinished projects about random dungeons and VB/DirectX
code to do the same that might be translatable into DB.

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.

Ah, I tend to use VB for such stuff as it handles a lot of the UI basics
for me. I really need to get my sample code into a 'releasable' format
:)

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.

See, you're mostly there anyway. I think from past failed projects the
UI can make or break a project such as this. If the players can't do
things as easily as they do IRL or the GM cannot control or fudge rules
as much as they can IRL then it isn't going to get much use.

Once you get a beta up be prepared for a lot of contradictory views
though. Most of my projects have failed because it is so difficult to
write something that is usable by most tabletoppers. I used to be the
secretary of the largest London based role play club and even with 140
player base I could only ever please under a third of the player base
with the tools that I wrote. There is just too much variation in what
people want or how they handle things to be specific, which is where you
may very well succeed by being more generic.

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.

Yes, but don't overdo it. Nothing worse than a menu that has 20+
options, or multiple sub-menus off the main menu. Pretty much every user
I know has issues with targetting sub menus off a menu because Windows
base method is not to focus just on the sub menu but to lose focus when
you move off either menu. I actually think this would be easier to
program in DB but in VB you can't easily force the first menu to stay
open whilst the sub menu is being navigated. Again modifer keys might
help here. You have to pick the situation you use them carefully and
testing will tell you when that is.
--
Alfie
<http://www.delphia.co.uk/>
A Law of Computer Programming: Make it possible for programmers to write in English and you will find the programmers cannot write in English.

.

Relevant Pages

  • Re: How I got interested in the Apple ][...
    ... have any concept of programming languages, and my only exposure to games was ... It didn't teach programming, but it ... the mid-90's and some of the more well-off schools were dumping the Apple IIs ... I found a IIc, a IIe, and between the podcasts and Virtual][a vibrant online Apple II community. ...
    (comp.sys.apple2)
  • Re: Best GUI- Python for children - pygame and blender32
    ... the students who were serious about learning ... about programming, to use the computer as a tool, never returned ... If you really want games I would look at David Ahl's old ... python to run on the web, your school will never forgive you. ...
    (comp.lang.python)
  • Re: To Richard Heathfield: enoughs enough
    ... about the real culture of programming which to her is ... games are fun and companies often exploit that to get unpaid ... > artifact like the C language. ... It's an expertise that enables them to earn their living as programmers. ...
    (comp.programming)
  • Re: Custom pinball report - Cosmic Colony in NorCal
    ... having learned a lot of my controls programming ... but will definitely extend this technology base with ... I've always thought that new rule-sets for older games ...
    (rec.games.pinball)
  • Re: Q: ANYONE HAVING LUCK OR SUCCESS CHARGING MORE THAN .50 PER PLAY?
    ... popular collector pins ever, and machines were maintained, the player base ... games until they cant boot up any longer and die from neglect. ... making money, but it can be overcome if you build a reputation and a ... you miss opportunities to improve your business because you linger ...
    (rec.games.pinball)