srussell@CSUFRES.CSUFRESNO.EDU (01/25/91)
I am looking for the latest version of Pararena. The version at sumex-aim is out of date. I read here some weeks back that the author, John Calhoun, has fixed a few minor but irritating bugs. I'd like to try the new version before I consider sending in my shareware fee. Would anyone out there be interested in uploading the most recent version of Pararena, either to sumex or comp.binaries.mac? -- Regards, -Steven Russell srussell@csufres.csufresno.edu
kevin@crash.cts.com (Kevin Hill) (01/26/91)
Could someone post Pararena (the Latest version) to comp.binaries.mac. I have been searching for the game for the longest time, and have not been able to find it here in San Diego? Or Ftp it to my site? Thanks... Kevin
mlab2@kuhub.cc.ukans.edu (01/26/91)
Sorry, I can't send it myself. I've NEVER been successful with mail, etc. FYI though, the new version (1.2) fixes a number of things. The high scores work properly, one opponent was made 'tougher', it fairly successfully ignores all INIT's, screensavers, etc. There are a bit of jazzed up graphics as well. I hope someone better with Unix can send it though. It's embarrassing seeing an old version of your programs still floating around (a lesson I now learned - the first release will always haunt you - do it right the first time. A corrollary (sp) to that is 2.0 is how 1.0 SHOULD have been done, and 3.0 is how 2.0 SHOULD have been done......). :) john calhoun
jsp@key.COM (James Preston) (04/02/91)
In article <1991Mar31.194518.1957@magnus.acs.ohio-state.edu> gaynor@magnus.acs.ohio-state.edu (Jim Gaynor) writes: > . . . >That means >that all of Soft Dorothy's stuff made it, in one way or another - and >the other three (Glider, Glypha, and Pararena) fairly dominate the top >five. You must be doing something right, John... 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. I ran it, decided to go right into a game to see what the heck it was like, and then got really pissed when the damned thing wouldn't let me quit! I then sat there and let the timer run out assuming that, surely it would put me back in a quittable mode at the end of the game. Surprise, surprise, it just restarted the timer (yes, I found out later about the series of periods). I tried hitting lots of command-keys, but nothing did anything. Finally, in desperation, I hit the restart button. Later, when I'd cooled off, I decided to experiment a little, and finally discovered that command-E sent me back to the menu. It was only then, after looking very carefully, that I noticed that the game did indeed tell me about command-E. IN A DAMNED *DIMMED* MENU ITEM! 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 thinking in NOT allowing it? Obviously, you are listening for command keys, since you catch command-E. What purpose is possibly served by ignoring command-Q? I mean, other than to frustrate your users? If you want to protect users from accidently qutting a game in progress, that is what dialogs are for. 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!!!! I am sure that I'm not the only Mac user who is sort of subconsciously trained to not pay much attention (if any at all) to dimmed menu items. I mean, if it's dimmed, I can't use it, so it can't be relevant right now, right?!? So who the hell would think to look to a dimmed menu item to find out how to get out of the game? 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
2fmlcalls@kuhub.cc.ukans.edu (04/02/91)
> 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
roths@berlin.rtp.dg.com (Robert Rothschild) (04/03/91)
In article <2515@key.COM> jsp@penguin.key.COM (James Preston) writes: > >Speaking of Pararena, does your comment there mean that the author is on >the net? (James then goes on to criticize several things about Parerena) James, Soft Dorothy has released several high quality shareware programs for the Macintosh. The games' author does this because of his enthusiasm for the Macintosh and the Macintosh community; certainly not for the financial rewards. If you don't like some features of his games, fine. Offer constructive criticism in a reasonable tone. Don't lambaste someone for doing such fine work for such humble rewards. Bob Rothschild roths@dg-rtp.dg.com
jsp@key.COM (James Preston) (04/04/91)
In article <1991Apr2.161624.24131@dg-rtp.dg.com> roths@berlin.rtp.dg.com (Robert Rothschild) writes: >James, > > Soft Dorothy has released several high quality shareware programs for >the Macintosh. The games' author does this because of his enthusiasm >for the Macintosh and the Macintosh community; certainly not for the >financial rewards. If you don't like some features of his games, fine. >Offer constructive criticism in a reasonable tone. Don't lambaste someone >for doing such fine work for such humble rewards. Bob, my Usenet postings are freeware; if you don't like them, then don't read them. If the game in question was a worthless piece of crap, I wouldn't have wasted my time pointing out its deficiencies. As I very clearly stated at the end of my posting, it is because the game is otherwise good that its deficiencies stand out so glaringly. The tone of my posting was meant to convey my level of frustration. I really think that "lambaste" is an overly harsh term to apply. Nevertheless, if you'd like to read something a little more reasonable, check out my response to the author. --James Preston
jsp@key.COM (James Preston) (04/04/91)
In article <1991Apr1.212723.29398@kuhub.cc.ukans.edu> 2fmlcalls@kuhub.cc.ukans.edu writes: >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? It's version 1.2.1. >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. But you already have a couple of help screens _in_ the program. I would say that you should include the command-E info -- perhaps highlighted in some way so that it stands out -- on one of those. >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). My point is that this thing should not be in the menu bar _at all_. As you say, it's not even really a menu item, so don't even put it there. I have no problem with disallowing menu access during the game, and I don't care how you handle events. The point is that this is a very crucial piece of information -- how the user gets out of game play mode -- and putting that crucial piece of information in a dimmed menu item just doesn't get that crucial message across. At the very least, you must provide a way for the user to get out of a game in progress when that user has no specific knowledge (i.e. when someone like me just starts it up to see what the game is like before having read anything about it). Even if you put detailed instructions on one of the help screens, you cannot prevent users from just going right into the game. Even if you put instructions on a start-up screen, you can't force anyone to read it. So the friendliest thing to do is to enable command-Q during game play. If you want to strictly conform to the guidelines, its action should be to exit from the application. However, I (and I think probably everyone else) would have no problem if its action were what now happens with command-E, i.e. to stop game play and put the user back in command-mode. From this mode, another command-Q would exit the application. This is the same number of keystrokes as the current situation (command-E, then command-Q), but it saves the user from needing to remember two different commands, it's probably a tiny bit easier for you to implement, it avoides the need for any special documentation, and it will certainly prevent the kind of frustration that I experienced. >A final note. In truth, I don't have any idea how to program. I'm NOT a >programmer. Well, if it walks like a duck, and quacks like a duck . . . Maybe you don't CALL yourself a programmer, but anyone who writes things like Pararena and Glypha most certainly has many "ideas how to program". Sorry, but you're a programmer, whether you like it or not. > . . . 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. Wrong. You most certainly do NOT lack the technical prowess. Your games are irrefutable evidence of your technical prowess. All you lack is a little knowledge about user interfaces. Besides, a good program is both interesting and well-crafted. That there exist programs that are one but not the other is no excuse for you to write programs that are the reverse. >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). I think, perhaps, you missed my point about the guidelines. I have no problem with programs that don't follow the guidelines _IF_ there is a good reason for it and IF said deviation is properly documented and explained. Pararena breaks from the guidelines in two ways (no command-Q from game play mode, and putting instructions in a dimmed menu item). Neither was justifiable nor explained. But the real problem is that the combination of the two led to at least one very frustrated user. And I'm willing to bet large sums of money that I am far from the only person who has experienced that. What you'll find, though, is that users of shareware -- particularly games -- have gotten used to sloppy programming and so just "live with it". I think there is no excuse for sloppy programming, even from self-proclaimed non- programmers, regardless of the cost of the software. (Not to toot my own horn, but just as proof that I practice what I preach, check out my shareware program, IntCalc, or my soon to be released game, Chello. I spent a lot of time on them and a significant portion of that time was an attempt to get the best user interface I could. I gave beta copies to friends and made many changes due to feedback about things that weren't adequately explained, or deviations from the guidelines, or things that just plain could have been done better. There is no way in hell that the shareware fees will amount to a fraction of what my time spent was worth. So I don't want anyone expecting me to be forgiving about a program's shortcomings just because it's shareware.) --James Preston
Thinker@gate.oxy.edu (05/24/91)
What is the new version of Pararena? I found 1.3 on Umich, and it looked like it had new things on resedit. However, the game crashes with ID=2 every time I tried to load. I stripped all the INITs out of my system folder. I am running a 2.5MB SE w/20MB HD. Thanks. P.S. I still want help on Legends of the Lost Realm!!!! Please!!! The Mad Thinker