Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!kuhub.cc.ukans.edu!2fmlcalls
From: 2fmlcalls@kuhub.cc.ukans.edu
Newsgroups: comp.sys.mac.games
Subject: Re: pararena (was Re: PD/SW Games list)
Message-ID: <1991Apr1.212723.29398@kuhub.cc.ukans.edu>
Date: 2 Apr 91 03:27:23 GMT
References: <1991Mar31.194518.1957@magnus.acs.ohio-state.edu> <2515@key.COM>
Organization: University of Kansas Academic Computing Services
Lines: 62

> Speaking of Pararena, does your comment there mean that the author is on
> the net?  If so, he gets three large "boo"s for the user-interface to this
> game.

{explanation of problem deleted}

> My complaints to the author are these:
> 
> 1) There is no excuse for not enabling command-Q to quit the entire game at
> all times.  No excuse at all.  This is part of the user-interface guidelines,
> and there is no reason that games should be excluded.  I mean, what was your
...

You're certainly right.  I haven't ever even see the user-interface guidelines,
but I can generally glean what's okay and not okay from other Mac programs. 
And, I certainly need to put the command-Q in there.  BTW, is this version 1.2? 
I thought I might have made a correction to some degree in 1.2 (maybe 1.1 was
just worse).

> 2) Putting an important instruction in a menu item has got to be the stupidest
> thing I have ever heard of on the Mac.  Menu items are for things that you
> can select, things that cause an action.  Not for instructions!!
> 
> 3) I take back what I said in number 2.  The stupidest thing I have ever
> heard of is putting an important instruction in a *DIMMED* menu item!!!!
...

Consider the dilemna though.  Documentation never follows a program.  Now
that's not my justifying using the menu bar to display info, because I don't
think it's that way at all.  Nonetheless, this is a game where you click and
drag all over the screen (were the cursor visible).  Allowing normal event
handling would cause all kinds of crazy things to happen without your intending
it.  Therefore, menu access is out of the question while the game is in play
(in fact I don't even call GNE or WNE).  The command-E is a 'faked' menu
command call.  The reason it is dimmed is because you can't end a game when a
game hasn't even started (at which point you don't get menu access - so - the
dilemna).  But, you're correct that I should try to find an alternative (and
atleast fake a command-Q).

> Your game ideas and general implementation skills are very good.  That is
> why it is all the more glaring when you commit blunders such as the above.
> 
> --James Preston

A final note.  In truth, I don't have any idea how to program.  I'm NOT a
programmer.  I'm certified to teach high school English and Physics - I've
never had any programming courses outside of an Intro. to Pascal.  I hate to
reinforce this dichotomy, but you know I see a lot of very well crafted
programs out there that follow (I'm sure) ALL of the user interface guidelines. 
Many of these though as games are a little boring or unoriginal.  I come up
with a lot of ideas, but lack the technical prowess to pull them off correctly.

A final final note - look at how many other games break interface guidelines
(like how many arcade games - popular ones - even HAVE a menu bar?).  Suppose
though if I use one I  should use it 100% correctly though (I already hear you
saying).

Final final final note.  I'll fix all problems with my software if I know how
and if peopel bring these things to my attention (eventually).  Oh, and it's
shareware by the way - so don't send me anything if you don't like it.

john calhoun